jconwell/secret_handshakemTLS के ऊपर x509 प्रमाणपत्रों का उपयोग करने वाला एक प्रोटोटाइप मैलवेयर C2 चैनल
सबसे पहले, मैं इसे ओपन सोर्स क्यों करूँ?
MITRE ATT&CK केवल चोरी किए गए या स्व-हस्ताक्षरित प्रमाणपत्रों की बात करता है, और NDRs (जहाँ तक मैं बता सकता हूँ) x509 प्रमाणपत्रों की सामग्री पर बहुत कम ध्यान देते हैं, सिवाय इसके कि जारी करने वाला CA कौन है। सामान्य तौर पर x509 प्रमाणपत्रों पर भरोसा किया जाता है और उन्हें बिना किसी रोक-टोक के हमारे फ़ायरवॉल से गुजरने की अनुमति होती है। लेकिन संक्षेप में वे सिर्फ़ फ़ाइलें हैं जो किसी भी अन्य फ़ाइल की तरह आसानी से दुर्भावनापूर्ण पेलोड धारण कर सकती हैं। हम उन पर भरोसा करते हैं और उन्हें अनदेखा करते हैं क्योंकि वे एक एन्क्रिप्शन प्रक्रिया का मुख्य घटक हैं, जिसे हम सामान्य मानने लगे हैं। इस परियोजना का प्राथमिक लक्ष्य एक ऐसे सुरक्षा संकेतक वर्ग के प्रति बढ़ी हुई जागरूकता लाना है जिस पर हम भरोसा करने लगे हैं, और उन तरीकों को उजागर करना है जिनका उपयोग इसके दुर्भावनापूर्ण उपयोगों का पता लगाने के लिए किया जा सकता है।
मैंने हमेशा सोचा कि क्या खतरे वाले अभिनेताओं (threat actors) ने कभी अपने C2 संचार के हिस्से के रूप में x509 प्रमाणपत्रों का उपयोग किया है, नेटवर्क ट्रैफ़िक को एन्क्रिप्ट करने के लिए नहीं, बल्कि वास्तव में C2 संचार को x509 प्रमाणपत्र में एम्बेड करने के लिए। 5 वर्षों तक जंगल में ऐसा कुछ खोजने के बाद, मैंने आखिरकार इसे स्वयं कोड करने का फैसला किया ताकि यह देख सकूँ कि क्या यह संभव है... और यह है।
HTTPS/TLS पर भेजा गया हर एक एन्क्रिप्टेड संदेश x509 प्रमाणपत्र के स्थानांतरण द्वारा सक्षम होता है। TLS हैंडशेक स्थापित करते समय (नीचे दिया गया चित्र), चौथे चरण के दौरान सर्वर अपना x509 प्रमाणपत्र क्लाइंट को भेजता है। क्लाइंट प्रमाणपत्र को सत्यापित करता है, सर्वर द्वारा समर्थित एन्क्रिप्शन एल्गोरिदम की तुलना करता है और चुनता है कि आगे के सभी संचार के लिए कौन सा एल्गोरिदम उपयोग करना है।
जैसा कि यह आरेख दिखाता है, यह केवल सर्वर से क्लाइंट तक x509 प्रमाणपत्र का एकतरफ़ा स्थानांतरण है। यह C2 संचार के लिए उपयुक्त नहीं है क्योंकि क्लाइंट के पास सर्वर को वापस जवाब देने का कोई तरीका नहीं है। अधिक से अधिक, इसका उपयोग केवल एकतरफ़ा डेटा स्थानांतरण तंत्र के रूप में किया जा सकता है (नीचे पूर्व कला अनुभाग देखें)।
लेकिन एक अन्य प्रकार का TLS सत्र है जिसे पारस्परिक TLS प्रमाणीकरण (mTLS) कहा जाता है, जहाँ क्लाइंट और सर्वर दोनों एक-दूसरे को प्रमाणित करने के तरीके के रूप में x509 प्रमाणपत्रों का आदान-प्रदान करते हैं।
जैसा कि उपरोक्त चित्र दिखाता है, पारस्परिक प्रमाणीकरण के दौरान सर्वर का x509 प्रमाणपत्र प्रमाणीकरण के लिए क्लाइंट को भेजा जाता है, और फिर क्लाइंट का x509 प्रमाणपत्र प्रमाणीकरण के लिए सर्वर को भेजा जाता है। आर्टिफैक्ट्स का यह आदान-प्रदान C2 सर्वरों के लिए 2-तरफ़ा संचार चैनल बनाने का एक अवसर दर्शाता है।
चूंकि सर्वर और क्लाइंट प्रमाणपत्र अंतर्निहित SSL लाइब्रेरी द्वारा आदान-प्रदान किए जाते हैं, इसलिए क्लाइंट के लिए एक ही mTLS कनेक्शन के भीतर सर्वर के प्रमाणपत्र से संदेश निकालने, कमांड चलाने और प्रतिक्रिया प्रमाणपत्र उत्पन्न करने का कोई अवसर नहीं होता है। इसका मतलब है कि C2 चैनल को इस तरह डिज़ाइन करने की आवश्यकता है कि अनुरोध-प्रत्युत्तर आदान-प्रदान दो अलग-अलग पारस्परिक TLS कनेक्शनों पर हो, लगभग छद्म-अर्ध-द्वैध (pseudo-half duplex) संचरण मोड की तरह।
अनुरोध/प्रतिक्रिया प्रक्रिया निम्नलिखित चरणों का पालन करती है:
जब मैंने इसे काम करते हुए देखा तो मुझे खुद पर काफ़ी गर्व हुआ कि मैं इतना रचनात्मक हूँ और सब कुछ।
फिर मुझे यह 2018 में जेसन रीव्स द्वारा BSides वार्ता मिली, जिन्होंने TLS पर x509 प्रमाणपत्रों का उपयोग करके एक मालवेयर बाइनरी ड्रॉपर लिखा था। एक साल बाद जेसन ने यह शोधपत्र प्रकाशित किया जिसमें mTLS का उपयोग करके एक पूर्ण 2-तरफ़ा संचार चैनल का विवरण दिया गया था।
mTLS के लिए आवश्यक है कि क्लाइंट और सर्वर दोनों के प्रमाणपत्रों पर एक ही CA प्रमाणपत्र द्वारा हस्ताक्षर किए गए हों, इसलिए पहला कदम अपनी स्वयं की CA निजी कुंजी / प्रमाणपत्र जोड़ी उत्पन्न करना है।
रूट CA निजी कुंजी बनाएँ:
openssl genrsa -des3 -out hmCA.key 2048
नोट: पासफ़्रेज़ किसी भी व्यक्ति को, जो आपकी निजी कुंजी प्राप्त कर लेता है, अपना स्वयं का रूट प्रमाणपत्र बनाने से रोकेगा।
रूट CA प्रमाणपत्र बनाएँ:
openssl req -x509 -new -nodes -key hmCA.key -sha256 -days 1825 -out hmCA.pem
उत्पन्न कुंजी और प्रमाणपत्र फ़ाइलों को certs/ca_certs फ़ोल्डर में कॉपी करें। प्रोजेक्ट एक डेमो कुंजी/प्रमाणपत्र जोड़ी के साथ आता है, इसलिए यदि आप चाहें तो इस चरण को छोड़ सकते हैं।
क्लाइंट प्रारंभ करें:
python client.py
सर्वर प्रारंभ करें:
python server.py
मैं कभी भी संभावित रूप से दुर्भावनापूर्ण कुछ जारी नहीं करना चाहता, बिना यह भी विवरण दिए कि इसे आपके नेटवर्क लॉग में कैसे पहचाना जाए।
आप सोचेंगे कि इस प्रकार के TLS पैटर्न का पता लगाना आसान होगा, लेकिन यह इतना सरल नहीं है। इस C2 चैनल के मुख्य संकेतों में से एक इसकी अर्ध-द्वैध (half-duplex) शैली का संचार है; सर्वर और क्लाइंट के बीच पूर्ण अनुरोध/प्रत्युत्तर पूरा करने के लिए दो पारस्परिक प्रमाणीकरण प्रवाहों की आवश्यकता होती है। फिर यह कई बार होगा क्योंकि सर्वर क्लाइंट को विभिन्न कमांड भेज रहा होता है।
इसका मतलब है कि आपको निम्नलिखित की तलाश करनी चाहिए:
यह पहचान नियमों का एक अचूक सेट लगता है, लेकिन जैसा मैंने पहले कहा, यह इतना आसान नहीं है। पता चलता है कि उद्यम सेवाओं का एक समूह है जिसमें समान mTLS ट्रैफ़िक पैटर्न भी है, जिनमें शामिल हैं:
इनमें से कई एसेट/डिवाइस प्रबंधन सेवाएँ प्रतीत होती हैं, इसलिए सिद्धांत रूप में उन्हें हर बार अपने सभी डिवाइसों पर चलने पर प्रमाणपत्रों का एक ही सेट भेजना चाहिए। आप देख सकते हैं कि क्या हर N घंटे में दोहराए जाने वाले कई mTLS सत्रों के सेट हैं, और फिर देखें कि क्या दो अलग-अलग सेटों के बीच प्रमाणपत्र हैश मेल खाते हैं, या अधिकतर मेल खाते हैं। साथ ही, संभावित रूप से देखें कि क्लाइंट प्रमाणपत्र प्रत्येक mTLS सत्र के लिए अलग-अलग हों, लेकिन सर्वर प्रमाणपत्र सभी सत्रों में समान हो।
SSL निरीक्षण इस प्रकार के C2 संचार चैनल को संभावित रूप से अवरुद्ध करने का एक तरीका है, क्योंकि SSL निरीक्षण सर्वर के पास क्लाइंट प्रमाणपत्र को प्रमाणित करने के लिए आवश्यक दुर्भावनापूर्ण CA प्रमाणपत्र नहीं होगा।
