synap5e/connectwise-automate-aitm-rceCVE-2025-11492, CVE-2025-11493 के लिए राइटअप और कोड - ConnctWise Automate RMM में Adversary-in-the-Middle के माध्यम से RCE
पेनेट्रेशन परीक्षण के हिस्से के रूप में, मैंने ConnectWise Automate रिमोट मॉनिटरिंग और मैनेजमेंट (RMM) एजेंट में कई असुरक्षाएँ खोजीं। कनेक्टवाइज़ का उपयोग कई प्रबंधित सेवा प्रदाता (MSPs) क्लाइंट डिवाइसों को प्रबंधित और मॉनिटर करने के लिए करते हैं। ये असुरक्षाएँ रिमोट कोड निष्पादन को सक्षम बनाती हैं यदि कोई हमलावर नेटवर्क Adversary-in-the-Middle स्थापित कर सकता है, या स्थानीय विशेषाधिकार वृद्धि और गुप्त स्थिरता (persistence) के रूप में उपयोग की जा सकती हैं यदि किसी हमलावर को कोड निष्पादन या ConnectWise Automate एजेंट चलाने वाले डिवाइस तक भौतिक पहुँच प्राप्त हो।
ये असुरक्षाएँ 20 अगस्त 2025 को ConnectWise को सूचित की गईं। ConnectWise ने CVE IDs निर्दिष्ट कीं और 16 अक्टूबर 2025 को संस्करण 2025.9 में एक पैच जारी किया।
ConnectWise बुलेटिन:
CVE IDs:
2025.9 जारी किया और सुरक्षा बुलेटिन और CVEs प्रकाशित किए।मैंने ConnectWise की त्वरित प्रतिक्रियाओं और सुधार के प्रति उनके सहयोगात्मक दृष्टिकोण तथा वर्गीकरण और सुधार के सर्वोत्तम तरीके पर चर्चा में शामिल होने की उनकी इच्छा की सराहना की।
इन असुरक्षाओं को वर्गीकृत करना एक दिलचस्प चुनौती थी। जबकि HTTPs पर स्विच करना इस रिपोर्ट के लगभग सभी परिदृश्यों को हल करता है, यह स्पष्ट था कि यह मूल रूप से एजेंट-सर्वर संचार की विश्वसनीयता में सुधार के लिए एक डिज़ाइन विकल्प (HTTP का समर्थन करना) था। एन्क्रिप्शन योजना आंशिक रूप से AiTM के जोखिम को स्वीकार/कम करने का प्रयास करती प्रतीत हुई, लेकिन इसे लगातार लागू नहीं किया गया था। इसकी गहराई से जाँच में यह वर्गीकृत करने का प्रयास शामिल था कि क्या कमजोरी http स्वयं थी या HTTP के ऊपर एन्क्रिप्शन की कमी, साथ ही रीप्ले रोकथाम, प्लगइन सत्यापन आदि सभी अपनी-अपनी असुरक्षाएँ थीं। एक समय पर ConnectWise असुरक्षाओं के विभिन्न पहलुओं के लिए 5+ अलग-अलग CVEs पर विचार कर रहा था।
इसके अतिरिक्त, दायरा और हमला वेक्टर इस बात पर निर्भर करते हुए बदल गए कि असुरक्षा को AiTM जैसे कॉफी शॉप Wi-Fi या LPE/भौतिक पहुँच परिप्रेक्ष्य से देखा गया था। एक वैकल्पिक दृष्टिकोण प्रत्येक परिदृश्य को एक अलग असुरक्षा के रूप में मानना होगा, जैसे AiTM RCE, LPE, Persistence अधिग्रहण, आदि।
एक अंतिम सीख यह है कि 2025 में भी, हम फ़ाइलों को प्रभावी ढंग से साझा करने में संघर्ष कर रहे हैं :D (ईमेल सुरक्षा को .dll फ़ाइलें या उनसे युक्त .zips ईमेल करना पसंद नहीं आया)।
यह रिपोर्ट ConnectWise द्वारा पैच जारी करने और CVEs के प्रकटीकरण के बाद प्रकाशित की जा रही है, और उनकी सहमति से कि ऐसा प्रकटीकरण उनके उपयोगकर्ताओं को नुकसान नहीं पहुँचाता। इसके अलावा, मेरा मानना है कि इन असुरक्षाओं और उनके शमन का सार्वजनिक प्रकटीकरण अन्य विक्रेताओं और सुरक्षा पेशेवरों को ConnectWise Automate और अन्य RMM प्रणालियों दोनों में जोखिमों को बेहतर ढंग से समझने और कम करने में मदद करेगा।
यह सामग्री केवल कानूनी, अधिकृत सुरक्षा अनुसंधान और शैक्षिक उद्देश्यों के लिए है। सिस्टम, नेटवर्क या डेटा से समझौता करने के लिए इस जानकारी का अनधिकृत उपयोग अवैध और अनैतिक है। सामग्री यथास्थिति (as-is) और बिना किसी प्रकार की वारंटी के प्रदान की गई है। लेखक इस जानकारी के उपयोग या दुरुपयोग से होने वाली किसी भी क्षति के लिए सभी दायित्व से इनकार करते हैं।
यदि आप इस कोड या जानकारी का उपयोग आगे के शोध के लिए कर रहे हैं, तो प्रभावित विक्रेता(विक्रेताओं) को किसी भी खोजी गई असुरक्षा की रिपोर्ट करके जिम्मेदार प्रकटीकरण का अभ्यास करें।
नीचे दी गई रिपोर्ट के अलावा, इस रिपॉजिटरी में असुरक्षाओं को प्रदर्शित करने के लिए PoC कोड शामिल है। नकली सर्वर कार्यान्वयन और उपयोग निर्देशों के विवरण के लिए automate_server/README.md देखें।
इस कोड का उपयोग ConnectWise Automate पर आगे (नैतिक) सुरक्षा अनुसंधान करने के लिए भी किया जा सकता है।
निम्नलिखित रिपोर्ट (या उसके करीब का संस्करण) और इस रिपॉजिटरी में मौजूद PoC पायथन कोड, अनुशंसित शमन के साथ ConnectWise को प्रदान किए गए थे।
हटाया गया शमन अनुभाग उन परिवर्तनों पर अधिक विस्तार से चर्चा करता है जो Automate एजेंट को इन असुरक्षाओं के विरुद्ध कई तरीकों से सख्त (harden) करने के लिए किए जा सकते हैं।
चूँकि इनमें से कुछ परिवर्तन अभी भी ConnectWise द्वारा विचाराधीन हैं, उस अनुभाग को इस सार्वजनिक प्रकटीकरण से हटा दिया गया है।
ConnectWise Automate रिमोट मॉनिटरिंग और मैनेजमेंट (RMM) एजेंट (अगस्त 2025 तक के नवीनतम संस्करण, संस्करण स्ट्रिंग 250.252 पर परीक्षण किया गया) कुछ कॉन्फ़िगरेशन में नेटवर्क-आधारित रिमोट कोड निष्पादन के प्रति असुरक्षित है। यदि एजेंट अपने Server Address के लिए एक अनएन्क्रिप्टेड HTTP ट्रांसपोर्ट (प्राथमिक रूप से या फ़ॉलबैक के रूप में) का उपयोग करने के लिए कॉन्फ़िगर किया गया है और कोई हमलावर एडवर्सरी-इन-द-मिडल (AiTM) हमला कर सकता है, तो वे SYSTEM के रूप में दूरस्थ रूप से कोड निष्पादित कर सकते हैं। यह कॉन्फ़िगरेशन कई प्रबंधित सेवा प्रदाताओं (MSPs) से वास्तविक दुनिया में देखा गया है।
शोषण तब भी संभव है जब हमलावर को डिवाइस तक भौतिक पहुँच एक गैर-व्यवस्थापक के रूप में मिलती है या अन्यथा डिवाइस को हमलावर-नियंत्रित नेटवर्क से जोड़ सकता है (अर्थात असुरक्षा का उपयोग स्थानीय विशेषाधिकार वृद्धि के रूप में किया जा सकता है)। हालाँकि Automate अधिकांश RMM कमांडों को एन्क्रिप्ट और सत्यापित करने के लिए एक एन्क्रिप्शन प्रणाली का उपयोग करता है, इसकी प्लगइन प्रणाली में पर्याप्त सुरक्षा का अभाव है और यह रिमोट कोड निष्पादन के प्रति संवेदनशील बनी हुई है।
Automate के नियंत्रण सर्वर की नकल करने वाला एक कस्टम सर्वर लागू करके, Automate एजेंट को एक दुर्भावनापूर्ण प्लगइन डाउनलोड और निष्पादित करने के लिए मजबूर किया जा सकता है।
समझौता किया गया एजेंट स्थिरता (persistence) का एक आकर्षक रूप भी प्रदान कर सकता है। RCE का उपयोग करके एजेंट की सममित एन्क्रिप्शन कुंजियाँ निकालकर, कस्टम सर्वर मानक RMM चैनल का उपयोग करके एजेंट को मनमाने कमांड भेज सकता है। AiTM परिदृश्य में, यह हमलावर को फ़ाइल निष्कर्षण, क्रेडेंशियल डंपिंग, कमांड निष्पादन और कॉन्फ़िगरेशन बदलने सहित मनमाने RMM कमांड निष्पादित करने की अनुमति देता है। हमलावर RMM के Server Address को अपने स्वयं के सर्वर पर भी संशोधित कर सकता है, जिससे AiTM के बाद भी गुप्त स्थिरता प्राप्त होती है। वैकल्पिक रूप से, RCE का उपयोग सीधे सिस्टम-स्तरीय कमांड चलाने के लिए किया जा सकता है।
Server Address का उपयोग करता है जिसमें http:// एंडपॉइंट शामिल है। दो अलग-अलग MSPs से असुरक्षित कॉन्फ़िगरेशन देखे गए हैं (वास्तविक MSP डोमेन और IPs बदल दिए गए हैं):
https://automate.msp-one.com|http://automate.msp-one.comhttps://msp.msp-two.com|http://msp.msp-two.com|http://12.346.6.78http:// एंडपॉइंट का उपयोग फ़ॉलबैक के रूप में किया जाता है यदि https:// कनेक्शन विफल हो जाता है, लेकिन एक हमलावर https को ब्लॉक करके इसका अनुकरण कर सकता है।Automate एजेंट को सर्वर पते के रूप में http:// URL का उपयोग करने के लिए कॉन्फ़िगर किया जा सकता है। यह कॉन्फ़िगरेशन संभवतः इंस्टॉलर स्क्रिप्ट/पैकेज द्वारा सेट किया जाता है, लेकिन रजिस्ट्री कुंजी HKLM\SOFTWARE\LabTech\Service\Server Address की जाँच करके इसे सत्यापित किया जा सकता है।
HTTPS और HTTP दोनों एंडपॉइंट्स का उपयोग करना, जो एक पाइप | द्वारा अलग किए गए हैं, सिद्धांततः यह सुनिश्चित करता है कि यदि HTTPS कनेक्शन में कोई समस्या आती है, तो Automate एजेंट HTTP कनेक्शन पर वापस आ जाएगा।
यदि कोई हमलावर Automate एजेंट और सर्वर के बीच नेटवर्क ट्रैफ़िक तक Adversary-in-the-Middle (AiTM) पहुँच प्राप्त कर लेता है, तो वे जानबूझकर HTTPS कनेक्शन को बाधित कर सकते हैं, जिससे यह HTTP पर वापस आ जाता है। यह हमलावर को एजेंट और सर्वर के बीच आदान-प्रदान किए गए ट्रैफ़िक को इंटरसेप्ट, मॉनिटर और बदलने की अनुमति देता है। फिर एक हमलावर ट्रैफ़िक को https://automate.msp-one.com पर रिवर्स प्रॉक्सी कर सकता है, जिसके परिणामस्वरूप एजेंट का "मानक संचालन" होता है, लेकिन हमलावर डेटा पर गुप्त रूप से नज़र रखने में सक्षम होता है। इसके अतिरिक्त, वे प्रतिक्रियाओं को इंजेक्ट या संशोधित कर सकते हैं या एक पूरी तरह से धोखाधड़ी वाला Automate सर्वर भी स्थापित कर सकते हैं जो Automate एजेंट के अनुरोधों का जवाब देता है।
यह एक "दुष्ट" (rogue) Wi‑Fi एक्सेस पॉइंट (hostapd, dnsmasq, IP फ़ॉरवर्डिंग + NAT) स्थापित करके और ट्रैफ़िक पुनर्निर्देशन के लिए iptables नियमों तथा रिवर्स प्रॉक्सी के लिए mitmproxy स्क्रिप्ट का उपयोग करके प्राप्त किया गया था।
अन्य, अधिक संवेदनशील डेटा जिसमें चल रहे प्रोग्राम, पूर्ण नेटवर्क कॉन्फ़िगरेशन और दस्तावेज़ पथ शामिल हैं, कभी-कभी Automate एजेंट प्रतिक्रियाओं में देखे गए हैं।
iptables -t nat -A PREROUTING -i wlx90916440139a -p tcp --dport 80 -j REDIRECT --to-port 8080 iptables -A FORWARD -i wlx90916440139a -p tcp --dport 443 -j DROP
#### mitmproxy स्क्रिप्ट:```python
# run with AiTMweb --mode transparent@8080 -s automate_AiTM.py
def request(flow: http.HTTPFlow):
if flow.request.pretty_host == 'automate.msp-one.com':
flow.request.url = 'https://automate.msp-one.com' + flow.request.path
ZTNA समाधान इस अवरोधन को थोड़ा जटिल कर सकते हैं, लेकिन आगे के mitmproxy स्क्रिप्ट द्वारा ZTNA को सशर्त रूप से पहचानने और ब्लॉक करने के कारण इन्हें विश्वसनीय रूप से बायपास कर दिया गया, जिसके परिणामस्वरूप गैर-टनल्ड HTTP पर वापसी हुई।
Automate एजेंट सर्वर के साथ संवाद करने के लिए HTTP के ऊपर एक कस्टम प्रोटोकॉल का उपयोग करता है।
डिवाइस पर मौजूद RMM एजेंट समय-समय पर सर्वर के /LabTech/agent.aspx एंडपॉइंट पर HTTP(S) अनुरोध भेजता है। प्रासंगिक अनुरोध प्रकार इस प्रकार हैं:
ध्यान दें कि पथों में असंगत कैपिटलाइज़ेशन कोई टाइपो नहीं है; यह वैसे ही है जैसे Automate एजेंट ये अनुरोध भेजता है। स्पष्टता के लिए सभी एंडपॉइंट पथ कोड टिक्स में लपेटे गए हैं।
/LabTech/Agent.aspx?DEPS का अनुरोध करता है और एक XML प्रतिक्रिया प्राप्त करता है जिसमें निर्भरता फ़ाइलों, उनके संस्करण संख्याओं और उनके चेकसम की सूची होती है।/LabTech/Agent.Aspx?DepCheck=1&DependancyId=<id> का अनुरोध करता है और एक ऑबफस्केटेड बाइनरी फ़ाइल प्राप्त करता है जिसमें निर्भरता एक छवि फ़ाइल के रूप में प्रच्छन्न होती है (संभवतः यह ऑबफस्केशन सामग्री फ़िल्टर को डाउनलोड ब्लॉक करने से रोकने के लिए है)।/LabTech/agent.aspx?<id>?c<CMD id>&<arg count> का अनुरोध करता है और कमांड-विशिष्ट डेटा युक्त एक कस्टम-पैक्ड प्रतिक्रिया प्राप्त करता है।InitialCommandRetrieve भी शामिल है), कमांड के परिणाम लौटाने और चैट करने के लिए किया जाता है।संवेदनशील "रिमोट कमांड" अक्सर एक DES3-आधारित एन्क्रिप्शन योजना का उपयोग करके एन्क्रिप्ट की जाती हैं, जिसमें पूर्वनिर्धारित system password और computer password से कस्टम कुंजी व्युत्पत्ति होती है। सही पासवर्ड के बिना, एक हमलावर एजेंट को भेजे गए वैध कमांड को देख/इंजेक्ट/संशोधित नहीं कर सकता; हालाँकि, कमांड प्रतिक्रियाएँ एन्क्रिप्टेड नहीं होती हैं और अक्सर संवेदनशील प्लेनटेक्स्ट डेटा शामिल करती देखी गई हैं, जिनमें खुली फ़ाइलें, पथ, उपयोगकर्ता नाम, इंस्टॉल किए गए प्रोग्राम आदि शामिल हैं।
निर्भरता जाँच (/LabTech/Agent.aspx?DEPS) और डाउनलोड (/LabTech/Agent.Aspx?DepCheck=1&DependancyId=<id>) एन्क्रिप्टेड या हस्ताक्षरित नहीं हैं, जिसका अर्थ है कि एक हमलावर प्रतिक्रिया में दुर्भावनापूर्ण निर्भरताएँ शामिल करने के लिए उसे संशोधित कर सकता है, जिन्हें RMM एजेंट द्वारा डाउनलोड और लोड किया जाएगा। यदि निर्भरता जाँच को एक अलग चेकसम शामिल करने के लिए जाली बनाया जाता है, तो RMM एजेंट बेमेल निर्भरता फ़ाइल के लिए एक नया डाउनलोड करेगा और उसे लोड करेगा (बशर्ते नई डाउनलोड की गई फ़ाइल जाली चेकसम से मेल खाती हो)। प्लगइन्स .NET असेंबली होते हैं जो एक विशिष्ट इंटरफ़ेस लागू करते हैं, और Automate एजेंट किसी भी .NET असेंबली को लोड करेगा जो अपेक्षित प्लगइन इंटरफ़ेस से मेल खाती है, फिर प्लगइन के इंटरफ़ेस को कॉल करेगा जिसके परिणामस्वरूप कोड निष्पादन होगा।
डाउनलोड किए गए प्लगइन निर्भरताओं के लिए सत्यापन का एक दूसरा स्तर भी है, जहाँ एजेंट एक cmdGetPlugins कमांड भेजता है और यह भी सत्यापित करता है कि चेकसम यहाँ मेल खाता है, लेकिन यह कमांड एन्क्रिप्शन योजना का उपयोग नहीं करता है।
dnSpy का उपयोग करके, एजेंट द्वारा उपयोग किए जाने वाले वैध ScreenConnectRemotePlugin.dll में दुर्भावनापूर्ण कोड इंजेक्ट करना संभव था। DEPS, DepCheck और cmdGetPlugins कमांड कार्यक्षमता वाला एक कस्टम Automate सर्वर बनाया गया था। नकली सर्वर ने अपेक्षित प्लगइन्स और निर्भरताओं की नकल की, लेकिन ScreenConnectRemotePlugin.dll के हैश को दुर्भावनापूर्ण रूप से संशोधित प्लगइन के लिए परिकलित हैश में बदल दिया। नकली सर्वर ने DepCheck अनुरोध के जवाब में दुर्भावनापूर्ण रूप से संशोधित ScreenConnectRemotePlugin.dll भी प्रदान किया (ऑबफस्केटेड नकली-छवि प्रारूप में) और cmdGetPlugins को भी हेरफेर किए गए हैश के साथ लागू किया। अंत में, mitmproxy स्क्रिप्ट को अपडेट किया गया ताकि Automate एजेंट को वैध (HTTPS) सर्वर के बजाय नकली सर्वर की ओर निर्देशित किया जा सके।
कनेक्शन पर, दुर्भावनापूर्ण प्लगइन एजेंट द्वारा डाउनलोड और लोड किया जाता है। इंजेक्ट किया गया कोड "system" और "computer" पासवर्ड को नकली सर्वर पर एक्सफ़िल्ट्रेट करता है। system और computer पासवर्ड रजिस्ट्री में संग्रहीत होते हैं लेकिन एक भारी ऑबफस्केटेड C# और नेटिव लाइब्रेरी द्वारा डिकोड किए जाते हैं। रजिस्ट्री मान निकालने के बजाय, पैच किया गया प्लगइन डिकोड किए गए मान प्राप्त करने के लिए रिफ्लेक्शन का उपयोग करता है, जिससे ऑबफस्केशन की रिवर्स इंजीनियरिंग करने का प्रयास बच जाता है। वैकल्पिक रूप से, रजिस्ट्री कुंजी HKLM\SOFTWARE\LabTech\Service की संपूर्ण सामग्री को एक्सफ़िल्ट्रेट किया जा सकता है और RMM एजेंट की एक प्रति के साथ नियंत्रित वातावरण में उपयोग करके .NET डीबगर की सहायता से रनटाइम पर पासवर्ड निकाले जा सकते हैं।
वैकल्पिक रूप से, प्लगइन का उपयोग सीधे सिस्टम-स्तरीय कमांड चलाने के लिए किया जा सकता है; हालाँकि, रहस्यों को निकालने से RMM एजेंट को स्वयं कमांड-एंड-कंट्रोल के रूप में उपयोग करना संभव हो गया और इसका मतलब था कि लगातार बना रहने वाला चैनल EDR द्वारा पहचाना नहीं गया। Server Address को हमलावर-नियंत्रित सर्वर में अपडेट करके दृढ़ता (पर्सिस्टेंस) प्राप्त की जा सकती है, जो वैकल्पिक रूप से डिवाइस को लापता दिखने से बचाने के लिए कमांड को वैध सर्वर पर अग्रेषित कर सकता है। अधिक विवरण के लिए 3. RMM कमांड-एंड-कंट्रोल टेकओवर देखें।
यह उम्मीद की जाती है कि भले ही डिफ़ॉल्ट कॉन्फ़िगरेशन में कोई प्लगइन स्थापित न हो, एक खाली प्लगइन (प्लगइन्स के लिए आवश्यक C# इंटरफ़ेस से मेल खाते हुए) संकलित किया जा सकता था और समान प्रभाव के लिए DEPS और cmdGetPlugins प्रतिक्रियाओं में डाला जा सकता था।
यह भी देखा गया कि सर्वर द्वारा UpdatePlugins नामक एक "रिमोट कमांड" लौटाई जा सकती है, जो एजेंट को प्लगइन अपडेट शुरू करने के लिए ट्रिगर करती है। चूँकि कमांड्स में रीप्ले सुरक्षा शामिल नहीं होती है, यदि कोई हमलावर किसी वैध सर्वर द्वारा भेजे जा रहे कमांड को देख सकता है, तो वे अपडेट ट्रिगर करने के लिए इसे किसी भी अन्य एजेंट पर रीप्ले कर सकते हैं। यह RCE भेद्यता को अतिरिक्त परिदृश्यों में शोषित करने में सक्षम बनाता है, जिससे इस भेद्यता का प्रभाव बढ़ जाता है।
स्व-अपडेट भी अनएन्क्रिप्टेड और बिना हस्ताक्षर के पाया गया। स्व-अपडेट के माध्यम से रिमोट कोड निष्पादन का प्रदर्शन नहीं किया गया, लेकिन ऐसा माना जाता है कि यह समान रूप से कमजोर है। स्व-अपडेट का दुर्भावनापूर्ण संशोधन गुप्त रूप से करना अधिक कठिन होगा और Automate एजेंट को तोड़ने का अधिक जोखिम है; हालाँकि, संभवतः एक्सेक्यूटेबल्स/DLLs में .NET कोड इंजेक्ट करने का समान तरीका काम करेगा। स्व-अपडेट प्रक्रिया का आगे पता नहीं लगाया गया क्योंकि प्लगइन RCE पर्याप्त था और अधिक विश्वसनीय माना गया।
यह भी संभव है कि स्व-अपडेट प्रक्रिया का शोषण केवल-रीबूट-पर-शोषण-योग्य सीमा का एक व्यवहार्य समाधान हो (उदाहरण के लिए, यदि स्व-अपडेट ट्रिगर करने के लिए कोई प्रतिक्रिया इंजेक्ट या रीप्ले की जा सकती है)।
2.1 में वर्णित दृष्टिकोण का उपयोग करके system password और computer password निकालने से, मनमाने "रिमोट कमांड" पेलोड और प्रतिक्रियाएँ बनाना संभव था। कुंजी व्युत्पत्ति योजना को पूरी तरह से रिवर्स इंजीनियर और पुनः लागू करने के बजाय, केवल LabTechCommonBase.dll को आयात करना और "computer password" से DES3 कुंजी उत्पन्न करने के लिए Utilities.LabTechHash.ComputeHash का उपयोग करना संभव था। DLL से निकाले गए परिकलित DES कुंजी और हार्डकोडेड IV का उपयोग करके, RMM एजेंट को मनमाने कमांड के साथ जवाब देना संभव था।```python
# IV extracted from decompiled LabTechSecurity.cs:
# this._initializationVector = new byte[] { 240, 3, 45, 29, 0, 76, 173, 59 };
iv = [240, 3, 45, 29, 0, 76, 173, 59]
# Helper functions for pythonnet, clr_loader, clr to load LabTechCommonBase.dll into python
labtech_net.setup_paths_and_references(str((Path(__file__).parent.parent / 'LTSvc').resolve()))
from LabTechCommonBase import Utilities
labtech_hash = Utilities.LabTechHash()
labtech_hash.ComputeHash(computer_password.encode('ascii')) # Use the exfiltrated computer password
byts = bytes(labtech_hash.GetDigestBytes())
cipher = DES3.new(byts, DES3.MODE_CBC, bytes(iv))
padded_data = pad(data.encode('utf-8'), DES3.block_size)
encrypted_data = cipher.encrypt(padded_data)
return base64.b64encode(encrypted_data).decode('utf-8')
फर्जी Automate सर्वर में विभिन्न "Agent Command" प्रकारों के लिए हैंडलर लागू किए गए थे, जिससे यह एजेंट को "Remote Commands" वापस भेज सकता था। इन कमांडों का उपयोग डिवाइस पर मनमाना कोड चलाने के लिए किया जा सकता है, जैसे पेलोड डाउनलोड करके निष्पादित करना, या डिवाइस पर नेटवर्क टनल स्थापित करना (उदाहरण के लिए, SOCKS प्रॉक्सी सेट करना जिसका उपयोग डिवाइस की ZTNA पहुंच के माध्यम से pivot करने के लिए किया जा सकता है)।
2.1 से तत्काल सफाई के लिए, सर्वर एन्क्रिप्टेड `UpdatePlugins` कमांड भेज सकता है और दुर्भावनापूर्ण रूप से संशोधित प्लगइन को ओवरराइड करने के लिए मूल वैध प्लगइन प्रदान कर सकता है। हमलावर अभी भी एजेंट के साथ इंटरैक्ट कर सकता है (यह मानते हुए कि पासवर्ड निकाले जा चुके हैं) और `Server Address` को हमलावर-नियंत्रित सर्वर में अपडेट करके स्थिरता बनाए रख सकता है।
कमांडों का मनमाना निष्पादन भी `Execute` कमांड का उपयोग करके ping चलाने के लिए प्रदर्शित किया गया था, जो व्यवस्थापक संदर्भ में डिवाइस पर सफलतापूर्वक निष्पादित किया गया। इसे `InitialCommandRetrieve` कमांड के रूप में परोसा जा सकता है या अन्य "agent commands"/चेक-इन के उत्तर में लौटाया जा सकता है।```python
# Extract the RemoteCommandIDs enum from LabTechCommonBase.Constants using pythonnet
REMOTE_CMD_IDS = get_RemoteCommandIDs()
REMOTE_CMD_IDS_r = {str(v): k for k, v in REMOTE_CMD_IDS.items()}
# `register_cmd_handler` registers a command handler for the `/LabTech/agent.aspx?c<id>` endpoint.
# The string 'InitialCommandRetrieve' is mapped back to ID `36`.
# The full set of "Agent Command" and their IDs can be extracted from `LabTechCommonBase.Constants.modEnums.AgentCommandIDs`
@register_cmd_handler('InitialCommandRetrieve')
async def initial_command_retrieve(_req: dict) -> str:
cmd = '*!*'.join([
'202706506',
str(REMOTE_CMD_IDS_r['Execute']),
'!!!'.join([
'CMD.exe',
'/c ping -t -l 1337 192.168.20.2'
])
])
encrypted_cmd = encrypt(cmd)
return '|||'.join([
len_b64_gzip( # Simple helper to return '{len(data)}-{base64(gzip(data))}'
encrypted_cmd
),
# Generate common [latest-version, FILETIME(), queued command(s), MD5 hashes] encoding string expected in "agent command" responses
make_p2(),
])
-l 1337 का उपयोग ping को 1337 बाइट्स का पेलोड आकार प्रयोग करने का निर्देश देता है, जिसे फिर दूसरे स्क्रीनशॉट में (1337 पेलोड बाइट्स + 42 हेडर बाइट्स = 1379 कुल बाइट्स) एक "कैनरी" के रूप में देखा जाता है।
अनुभाग को सार्वजनिक प्रकटीकरण से हटा दिया गया है।