जब कोई भरोसेमंद क्लाउड एप्लिकेशन हमले का रास्ता बन जाता है

मालिक द्वारा उपलब्ध कराया गया वैचारिक चित्र। यह नहीं दिखाता कि कितने ग्राहक tenants प्रभावित हुए, और किसी tenant संख्या का संकेत नहीं देता।

October 2026 की ConnectWise Cloud Backup से जुड़ी एक घटना ने ऐसा सुरक्षा जोखिम उजागर किया जो कर्मचारियों के अकाउंट से आगे जाता है। हमलावरों ने भरोसेमंद एप्लिकेशन से जुड़े credentials का उपयोग करके Microsoft 365 ग्राहक वातावरणों में authenticate किया। इससे दिखता है कि थर्ड-पार्टी एप्लिकेशन की पहचानें किसी संगठन की सुरक्षा सीमा का हिस्सा हैं।

एप्लिकेशन भरोसेमंद था। उसका credential नहीं।

संगठन नियमित रूप से थर्ड-पार्टी एप्लिकेशन को अपने Microsoft 365 वातावरण तक पहुँचने की अनुमति देते हैं। उदाहरण के लिए, किसी क्लाउड बैकअप सेवा को Exchange Online, SharePoint, OneDrive और अन्य सेवाओं से जानकारी लेने की अनुमति चाहिए। वह इस पहुँच का उपयोग बैकअप बनाने और restoration में मदद के लिए करती है।

बैकअप सेवा को तब भी काम करना होता है जब कोई कर्मचारी साइन इन न हो। इसलिए संगठन हर निर्धारित ऑपरेशन के लिए किसी व्यक्ति की मंज़ूरी माँगने के बजाय एप्लिकेशन की पहचान को अधिकृत करता है।

October 2026 में यही व्यवस्था ConnectWise Cloud Backup से जुड़ी एक सुरक्षा घटना के केंद्र में आ गई, जिसे पहले SkyKick कहा जाता था। ConnectWise ने अपने क्लाउड बैकअप वातावरण से जुड़ी एप्लिकेशन पहचानों से जुड़े अनधिकृत एक्सेस की पुष्टि की। स्वतंत्र सुरक्षा जाँचकर्ताओं ने हमलावरों को उन्हीं पहचानों के ज़रिए Microsoft 365 ग्राहक tenants के विरुद्ध authenticate करते देखा।

October 15 को Sophos X-Ops ने स्वचालित authentication अनुरोधों की पहचान की, जिनमें ConnectWise Cloud Backup की एप्लिकेशन पहचान का उपयोग Microsoft Graph access tokens पाने के लिए किया गया था। Huntress ने स्वतंत्र रूप से October 16 को 19:00 UTC तक 162 ग्राहक tenants में अनधिकृत साइन-इन की जानकारी दी।

ये निष्कर्ष स्थापित करते हैं कि भरोसेमंद एप्लिकेशन पहचानों का उपयोग बिना अनुमति के हो रहा था। वे यह स्थापित नहीं करते कि सभी 162 tenants में डेटा चोरी, प्रशासनिक समझौता या हमलावर की स्थायी पहुँच हुई।

जाँचकर्ताओं ने कम से कम एक tenant में एप्लिकेशन-permission और credential में अधिक गंभीर बदलाव भी देखे। इन निष्कर्षों की अलग से जाँच ज़रूरी है, क्योंकि उपलब्ध प्रमाण यह स्थापित नहीं करते कि संबंधित सारी गतिविधि एक ही हमलावर ने की थी। स्रोत: ConnectWise Trust Center, Sophos X-Ops investigation और Huntress investigation।

बैकअप एप्लिकेशन Microsoft 365 तक कैसे पहुँचता है

इस घटना को समझने के लिए कर्मचारी की पहचान और एप्लिकेशन की पहचान को अलग करना ज़रूरी है। जब कोई कर्मचारी Outlook खोलता है, तो Microsoft Entra ID संगठन की साइन-इन शर्तों के अनुसार उस व्यक्ति को authenticate करता है। इनमें multifactor authentication, डिवाइस जाँच और Conditional Access policies शामिल हो सकती हैं।

स्वचालित बैकअप सेवा अलग तरह से काम करती है। उसे बिना किसी कर्मचारी की मौजूदगी के जानकारी तक पहुँचना होता है। Microsoft Entra इसके लिए एप्लिकेशन पहचानों का समर्थन करता है, जो सॉफ़्टवेयर को authenticate करने और सेवाओं तक पहुँच माँगने देती हैं।

कई संगठनों द्वारा उपयोग किए जाने वाले थर्ड-पार्टी एप्लिकेशन के लिए Microsoft Entra दो संबंधित objects में अंतर करता है। Application registration (एप्लिकेशन पंजीकरण) सॉफ़्टवेयर एप्लिकेशन का प्रतिनिधित्व करता है। प्रकाशक इसे अपने ही tenant में सँभालता है, जिसमें एप्लिकेशन को authenticate करने वाले credentials भी शामिल हैं।

Service principal (सेवा प्रिंसिपल) किसी खास ग्राहक tenant के भीतर उस एप्लिकेशन की मौजूदगी का प्रतिनिधित्व करता है। यह वह स्थानीय पहचान देता है जिसके ज़रिए permissions और पहुँच सौंपी जा सकती है। इसलिए एक multitenant एप्लिकेशन के पास प्रकाशक द्वारा नियंत्रित एक application registration और कई ग्राहक संगठनों में अलग-अलग service principals हो सकते हैं।

यह software-as-a-service प्लेटफ़ॉर्म द्वारा उपयोग किया जाने वाला सामान्य डिज़ाइन है। हर ग्राहक तय करता है कि एप्लिकेशन को अधिकृत करना है या नहीं और कौन-सी permissions देनी हैं। एप्लिकेशन अपनी पहचान साबित करने के लिए जिस credential का उपयोग करता है, उसे आमतौर पर वेंडर नियंत्रित करता है।

Microsoft इस संबंध को application objects and service principals पर अपने मार्गदर्शन में दर्ज करता है।

एप्लिकेशन का साइन-इन कैसे काम करता है

एक बैकअप सेवा पर विचार करें जो किसी ग्राहक tenant से जानकारी ले रही है। एप्लिकेशन किसी समर्थित credential, जैसे client secret या certificate, का उपयोग करके Microsoft Entra में authenticate करता है और किसी खास resource के लिए access token माँगता है।

Microsoft Entra एप्लिकेशन की पहचान को सत्यापित करता है, लागू authorization और policy आवश्यकताओं का मूल्यांकन करता है, और तय करता है कि अनुरोध मंज़ूर हो सकता है या नहीं। अगर ये जाँचें सफल होती हैं, तो Entra माँगे गए resource के लिए एक access token जारी करता है, जो एप्लिकेशन की अधिकृत permissions को दर्शाता है। एप्लिकेशन वह token Microsoft Graph को प्रस्तुत करता है, जो मूल्यांकन करता है कि माँगा गया ऑपरेशन अनुमत है या नहीं।

इसमें दो अलग सुरक्षा निर्णय शामिल हैं। Authentication स्थापित करता है कि अनुरोध कौन-सी पहचान कर रही है। Authorization तय करता है कि वह पहचान किस तक पहुँच सकती है या क्या बदल सकती है।

एक वैध एप्लिकेशन credential हर Microsoft 365 tenant या सेवा तक असीमित पहुँच नहीं देता। पहुँच लक्ष्य tenant में एप्लिकेशन की मौजूदगी, उसे दी गई permissions और लागू किसी भी पाबंदी पर निर्भर करती है।

Microsoft Entra दो अहम permission मॉडल का समर्थन करता है। Delegated permissions के साथ एप्लिकेशन साइन-इन किए हुए यूज़र के संदर्भ में काम करता है। Application permissions के साथ सॉफ़्टवेयर बिना साइन-इन यूज़र के, अपनी अधिकृत permissions के दायरे में काम कर सकता है।

ConnectWise की token गतिविधि में OAuth 2.0 client-credentials मॉडल के ज़रिए application-only authentication शामिल था। इससे समझ आता है कि हमलावर को किसी कर्मचारी का पासवर्ड पाने या उस कर्मचारी की सामान्य interactive MFA चुनौती पूरी करने की ज़रूरत क्यों नहीं पड़ी।

इसका मतलब यह नहीं कि MFA ने ठीक से काम नहीं किया। न ही इसका मतलब है कि एप्लिकेशन पहचानों पर कोई सुरक्षा नियंत्रण नहीं होते। इसका मतलब है कि हमलावर किसी इंसानी यूज़र के बजाय एक workload identity के रूप में authenticate करने का प्रयास कर रहा था।

सुरक्षा सीमा तब विफल हुई जब हमलावर को ऐसा credential मिल गया जो उस एप्लिकेशन की पहचान साबित करने में सक्षम था जिसे ग्राहक पहले ही अधिकृत कर चुके थे।

एक credential कई संगठनों तक कैसे पहुँच सकता था

ConnectWise Cloud Backup को कई Microsoft 365 tenants में काम करने के लिए डिज़ाइन किया गया था। हर ग्राहक का अपना वातावरण था और उसने अपनी ही authorization प्रक्रिया से एप्लिकेशन को पहुँच दी थी। फिर भी, वेंडर द्वारा नियंत्रित एप्लिकेशन credential का उपयोग सहमति देने वाले ग्राहक tenants में उसी एप्लिकेशन पहचान को authenticate करने के लिए किया जा सकता था।

इसलिए उस credential को रखने वाला हमलावर हर संगठन के कर्मचारी अकाउंट को अलग से compromise किए बिना एक से अधिक संगठनों के विरुद्ध authentication का प्रयास कर सकता था। Sophos ने October 15 को स्वचालित token sweep के दौरान यह तरीका देखा।

अनुरोध 144.172.64[.]128 पर एक virtual private server (VPS) से आए और एक व्यवस्थित क्रम में ग्राहक tenants को लक्षित किया। Sophos ने गतिविधि को लगभग 96 मिनट तक देखा और बताया कि वह यह तय नहीं कर सका कि हमलावर ने जारी किए गए tokens से अंततः क्या किया। Huntress ने स्वतंत्र रूप से उसी स्रोत इन्फ़्रास्ट्रक्चर से जुड़ा अनधिकृत authentication देखा, हालाँकि उसकी जाँच tenants और अवलोकनों के एक अलग समूह को कवर करती थी।

तकनीकी महत्व यह है कि हमलावर उस authorization संबंध का उपयोग कर रहा था जो हर ग्राहक और वेंडर के एप्लिकेशन के बीच पहले से मौजूद था। ग्राहक tenants एक सुरक्षा वातावरण में नहीं मिले थे। हर एक ने अपनी permissions और नियंत्रण बनाए रखे। लेकिन वही compromised वेंडर credential हर उस जगह प्रस्तुत किया जा सकता था जहाँ वह एप्लिकेशन अधिकृत था।

बैकअप सेवा के लिए दी गई permissions में mailboxes, फ़ाइलों, directory जानकारी और restoration के लिए ज़रूरी ऑपरेशन तक पहुँच शामिल हो सकती है। access token पाने वाला हमलावर संभावित रूप से उस token द्वारा दर्शाई गई permissions का उपयोग कर सकता था।

फिर भी, प्रमाणों की व्याख्या सावधानी से करनी होगी। authentication अनुरोध सफल साइन-इन के बराबर नहीं है। सफल साइन-इन ज़रूरी नहीं कि इस बात का प्रमाण हो कि माँगा गया Microsoft Graph ऑपरेशन सफल हुआ। और वैध token यह स्थापित नहीं करता कि ग्राहक की जानकारी डाउनलोड या संशोधित की गई।

ये अलग-अलग निष्कर्ष हैं जिनके लिए अलग-अलग प्रमाण चाहिए। स्रोत: Sophos X-Ops technical analysis और Huntress incident investigation।

जाँच ने स्थायी पहुँच के एक रास्ते की भी पहचान की

अनधिकृत token अनुरोध अकेली चिंताजनक बात नहीं थे। Huntress ने October 15 को एक ग्राहक tenant में एप्लिकेशन-पहचान के बदलावों का एक अलग क्रम दर्ज किया।

लगभग 03:44 और 03:49 UTC के बीच ConnectWise Cloud Management – MS Teams नाम के एक संबंधित एप्लिकेशन ने खुद को Global Administrator directory role सौंप लिया। उसी अवधि में उसने दो अन्य एप्लिकेशन पहचानों को संशोधित किया और उनमें नए client secrets जोड़े।

उनमें से एक पहचान एक MSP प्रबंधन एप्लिकेशन की थी। दूसरी उस tenant में Huntress Security Platform एप्लिकेशन की थी। Huntress ने बाद में अपने एप्लिकेशन से जुड़े एक अनधिकृत credential से सफल authentication की पहचान की।

ये अवलोकन दिखाते हैं कि क्लाउड पहचान की जाँच में एप्लिकेशन-credential के बदलाव क्यों मायने रखते हैं।

दूसरा credential अलग पहुँच का रास्ता कैसे बनाता है

Client secret किसी एप्लिकेशन को उसकी पंजीकृत पहचान के रूप में authenticate करने देता है। अगर हमलावर के पास किसी दूसरे एप्लिकेशन में नया secret जोड़ने की पर्याप्त authorization है, तो वह उस एप्लिकेशन की पहचान और उसकी मौजूदा permissions का उपयोग करके authenticate कर सकता है। इससे मूल compromised credential से अलग पहुँच का एक रास्ता बन जाता है।

उदाहरण के लिए, ConnectWise Cloud Backup की पहचान को अक्षम करने से किसी असंबंधित प्रबंधन एप्लिकेशन में जोड़ा गया अनधिकृत secret अपने आप नहीं हटेगा। दूसरे एप्लिकेशन की जाँच करनी होगी और उसके अनधिकृत credentials को उपयुक्त response प्रक्रिया से हटाना या अमान्य करना होगा।

फिर भी, किसी एप्लिकेशन का credential होने से अपने आप दूसरे एप्लिकेशन को संशोधित करने या विशेषाधिकार वाली role सौंपने का अधिकार नहीं मिल जाता। उन कार्यों के लिए अलग permissions या privileges चाहिए। यह अंतर खास तौर पर इसलिए अहम है क्योंकि घटना में अलग-अलग authorization संबंधों वाली कई ConnectWise एप्लिकेशन पहचानें शामिल थीं।

जाँचकर्ता क्या स्थापित कर सके और क्या नहीं

देखी गई गतिविधि का समय मायने रखता है। Huntress ने Global Administrator असाइनमेंट और अतिरिक्त credential बनाने को पहचाने गए सार्वजनिक IP पते से बाद की authentication गतिविधि से पहले दर्ज किया।

पहले की घटनाओं में Microsoft-hosted private address space से दर्ज ट्रैफ़िक शामिल था। Huntress यह स्थापित नहीं कर सका कि पहले की गतिविधि और बाद का सार्वजनिक-IP token sweep एक ही ऑपरेटर ने किया। उसने ऐसी अन्य एप्लिकेशन role-assignment गतिविधि भी देखी जो वैध ConnectWise automation जैसी लगती थी, जिसकी हमलावर पर अपने आप आरोप लगाने के बजाय आगे जाँच की ज़रूरत थी।

October 21 को ConnectWise ने कहा कि उसके पास उपलब्ध प्रमाणों के आधार पर, जिनमें Microsoft द्वारा साझा की गई threat intelligence भी शामिल है, ऐसा प्रतीत होता है (it appears) कि ConnectWise Cloud Backup पर हमले के लिए चीन से जुड़ा एक state-aligned समूह ज़िम्मेदार था, और उस समूह ने सार्वजनिक रूप से उपलब्ध एक agentic AI framework का उपयोग किया। यह वेंडर का आकलन है। Sophos ने किसी actor का नाम नहीं लिया, और Huntress ने पहले और बाद के गतिविधि-चरणों को एक ही ऑपरेटर से नहीं जोड़ा था। स्रोत: ConnectWise Trust Center।

इसलिए प्रमाण एक सटीक निष्कर्ष का समर्थन करते हैं:

कई ग्राहक tenants में अनधिकृत एप्लिकेशन authentication हुआ, और कम से कम एक tenant में credential-persistence का एक अलग, चिंताजनक क्रम दर्ज किया गया। इन गतिविधियों के बीच का पूरा संबंध स्थापित नहीं हुआ।

इन्हें एक ऐसे हमले के क्रम के रूप में बताना गलत होगा जिसे निर्णायक रूप से दोबारा बनाया गया हो और जो हर ग्राहक को प्रभावित करता हो। स्रोत: Huntress, ConnectWise/SkyKick vendor credential investigation।

वेंडर की रोकथाम से ग्राहक का remediation पूरा क्यों नहीं हुआ

ConnectWise ने जाँच के दौरान प्रभावित एप्लिकेशन पहचानों को अक्षम करके, credentials रद्द करके और संबंधित क्लाउड सेवाओं को निलंबित करके जवाब दिया। उसके October 18 के मार्गदर्शन के अनुसार कंपनी ने October 17 को 07:00 UTC पर सात ConnectWise एप्लिकेशन पहचानें अक्षम कीं।

उस कार्रवाई ने प्रभावित कनेक्शनों से नए authentication को रोका। उसने ग्राहकों के Microsoft 365 tenants के भीतर पहले किए गए बदलावों को अपने आप पलटा नहीं। पहले जारी किए गए tokens समाप्ति या प्रभावी अमान्यकरण तक वैध रह सकते थे। इससे भी अहम बात यह कि अलग पहचानों पर बने अतिरिक्त credentials, permissions या विशेषाधिकार वाले असाइनमेंट की अपनी अलग जाँच ज़रूरी थी।

वेंडर द्वारा किसी एप्लिकेशन कनेक्शन को अक्षम करने और ग्राहक द्वारा अपने tenant में संबंधित enterprise application की स्थिति सत्यापित करने के बीच भी अंतर है। ये दो अलग प्रशासनिक नियंत्रण हैं।

इसका मतलब है कि incident response के दो जुड़े हुए हिस्से हैं। ConnectWise को अपने एप्लिकेशन credentials सुरक्षित करने, अपनी सेवाओं की जाँच करने और यह पुष्टि करने की ज़रूरत है कि प्रभावित कनेक्शन कब सुरक्षित रूप से बहाल हो सकते हैं। ग्राहक प्रशासकों और managed service providers को यह स्थापित करना होगा कि जिन tenants की उनकी ज़िम्मेदारी है, उनमें अनधिकृत गतिविधि हुई या नहीं।

प्रशासकों को क्या जाँचना चाहिए

जाँच असंबंधित credentials को अंधाधुंध बदलने के बजाय प्रभावित एप्लिकेशन पहचानों से जुड़े प्रमाणों पर केंद्रित होनी चाहिए।

Service-principal sign-in records workload पहचानों से जुड़े authentication को दिखा सकते हैं। ये घटनाएँ कर्मचारियों की सामान्य साइन-इन गतिविधि से अलग हैं और हो सकता है कि प्रशासक जिन रिपोर्टों को नियमित रूप से देखते हैं उनमें दिखाई न दें।

Microsoft Entra audit logs एप्लिकेशन credentials, permissions, service principals और directory-role असाइनमेंट में बदलावों की पहचान कर सकते हैं। जाँचकर्ताओं को देखना चाहिए कि किस पहचान ने बदलाव शुरू किया, कौन-सी पहचान संशोधित हुई और क्या कोई अनपेक्षित credential बाद में इस्तेमाल हुआ।

ConnectWise October 13, 2026 से शुरू होने वाली प्रासंगिक गतिविधि की समीक्षा की सिफ़ारिश करता है, और जहाँ उपलब्ध प्रमाण ज़रूरत बताएँ वहाँ जाँच का दायरा बढ़ाने की भी। Sophos और Huntress भी घटना-विशिष्ट संकेतक देते हैं, जिनमें स्रोत पते, एप्लिकेशन पहचानें और देखे गए client software शामिल हैं।

उन संकेतकों की व्याख्या संदर्भ में होनी चाहिए। संदिग्ध IP पता जाँच में मदद कर सकता है, लेकिन उस पते की अनुपस्थिति यह साबित नहीं करती कि कोई tenant प्रभावित नहीं हुआ। इसी तरह Microsoft-hosted private नेटवर्क पते वैध गतिविधि में भी दिख सकते हैं और अपने आप किसी हमलावर की पहचान नहीं कराते।

एक और अहम सीमा दृश्यता से जुड़ी है। Microsoft Entra sign-in records स्थापित कर सकते हैं कि एक एप्लिकेशन ने authenticate किया। Audit logs पहचान और permission में बदलाव दिखा सकते हैं। वे ज़रूरी नहीं कि हर वह जानकारी दर्ज करें जो एप्लिकेशन ने बाद में Microsoft Graph के ज़रिए पढ़ी।

जहाँ अतिरिक्त Graph activity logs उपलब्ध हैं, वे जाँचकर्ताओं को बाद के किए गए ऑपरेशन स्थापित करने में मदद कर सकते हैं। उनकी उपलब्धता और कवरेज tenant की configuration, licensing और logging व्यवस्था पर निर्भर करती है। इसलिए, डेटा-एक्सेस की किसी घटना का न दिखना हमेशा यह स्थापित नहीं कर सकता कि कोई एक्सेस हुआ ही नहीं।

प्रशासकों को प्रासंगिक प्रमाण सुरक्षित रखने चाहिए, एप्लिकेशन की स्थिति सत्यापित करनी चाहिए और प्रभावित एप्लिकेशन को अक्षम या फिर से कनेक्ट करते समय वेंडर का ताज़ा मार्गदर्शन अपनाना चाहिए। एप्लिकेशन objects को तुरंत हटा देने से उपयोगी जाँच-संदर्भ मिट सकता है। incident-response मार्गदर्शन प्रभावित कनेक्शनों को अक्षम करने की सिफ़ारिश करता है, साथ ही वह सब सुरक्षित रखने की जो उनकी गतिविधि समझने के लिए चाहिए।

केवल कर्मचारियों के पासवर्ड बदलने या यूज़र sessions रद्द करने से एप्लिकेशन पहचानों से जुड़े अनधिकृत credentials का समाधान नहीं होता। स्रोत: ConnectWise Trust Center and remediation guidance, Sophos X-Ops investigation और Huntress technical findings।

ग्राहकों के बैकअप पर असर

सुरक्षा जाँच से परिचालन में भी बाधा आई। ConnectWise ने अपना वातावरण सुरक्षित करने और प्रभावित एप्लिकेशन कनेक्शनों को मान्य करने के दौरान Cloud Backup और संबंधित सेवाओं को निलंबित कर दिया। निलंबन के दौरान निर्धारित बैकअप ऑपरेशन, archive एक्सेस और restoration क्षमताएँ बाधित रहीं।

ConnectWise ने बताया कि मौजूदा Cloud Backup archives encrypted और अलग-थलग रहे, और उस समय इस बात का कोई संकेत नहीं था कि उन archives से समझौता हुआ। यह निष्कर्ष प्रदाता के सहेजे गए बैकअप से जुड़ा है। यह स्थापित नहीं करता कि अनधिकृत एप्लिकेशन authentication से हर ग्राहक का live Microsoft 365 वातावरण अप्रभावित रहा।

हमलावर संभावित रूप से बैकअप एप्लिकेशन को दी गई Microsoft Graph permissions का उपयोग करके live tenant की जानकारी तक पहुँच सकता था, उस अलग archive से समझौता किए बिना जहाँ पहले बैकअप किया गया डेटा रखा जाता है। इसलिए दोनों चिंताओं को अलग रखना होगा: मौजूदा बैकअप archives की सुरक्षा और live ग्राहक वातावरणों में अनधिकृत एक्सेस।

ConnectWise ने October 21 को चरणबद्ध सेवा बहाली शुरू की, लेकिन इसका मतलब यह पुष्टि नहीं थी कि सभी सेवाएँ पुनः चालू हो गईं या सभी प्रभावित ग्राहक tenants की जाँच पूरी हो गई। प्रशासकों को निर्देश दिया गया कि औपचारिक बहाली और फिर से कनेक्ट करने का मार्गदर्शन जारी होने तक प्रभावित एप्लिकेशन कनेक्शन अक्षम रखें। स्रोत: ConnectWise Trust Center।

यह घटना क्या दिखाती है

ConnectWise की घटना यह स्थापित नहीं करती कि थर्ड-पार्टी Microsoft 365 एप्लिकेशन स्वाभाविक रूप से असुरक्षित हैं। क्लाउड बैकअप और प्रबंधन प्लेटफ़ॉर्म को अपनी सेवाएँ देने के लिए ग्राहक वातावरणों तक पहुँच चाहिए। Multitenant एप्लिकेशन पहचानें और application-only authentication उस आर्किटेक्चर के सामान्य हिस्से हैं।

जोखिम तब उभरता है जब हमलावर को वह credential मिल जाता है जो उस एप्लिकेशन की पहचान साबित करने के लिए इस्तेमाल होता है जिसे ग्राहक पहले ही अधिकृत कर चुके हैं।

इस मामले में जाँचकर्ताओं ने कई ग्राहक tenants में अनधिकृत एप्लिकेशन authentication की पुष्टि की। Huntress ने एक खास tenant में विशेषाधिकार वाले एप्लिकेशन बदलाव और अनधिकृत credentials भी दर्ज किए, साथ ही गतिविधि के अलग-अलग चरणों का श्रेय तय करने की सीमाओं को स्पष्ट रूप से स्वीकार किया।

ये निष्कर्ष समझाते हैं कि मूल वेंडर credential को बदलना ज़रूरी तो था, पर यह स्थापित करने के लिए काफ़ी नहीं था कि हर ग्राहक वातावरण सुरक्षित है। संगठनों को यह भी तय करना था कि क्या अलग पहचानों, permissions या credentials के ज़रिए पहुँच बढ़ाई गई थी।

Microsoft 365 संगठन की सुरक्षा सीमा में वे थर्ड-पार्टी एप्लिकेशन भी शामिल हैं जिन्हें वह अधिकृत करता है, केवल वे लोग नहीं जो उसके सिस्टम में साइन इन करते हैं।

यूज़र अकाउंट की सुरक्षा ज़रूरी बनी रहती है। एप्लिकेशन पहचानों को समझना और उनकी निगरानी करना एक अलग ज़िम्मेदारी है, खासकर तब जब एक अकेला वेंडर-नियंत्रित credential कई ग्राहक tenants में भरोसेमंद माना जा सकता हो।

और गहराई में

शोध की समीक्षा October 21, 2026 को की गई। घटना की जाँच में और निष्कर्ष सामने आ सकते हैं। Tenants की संख्याएँ तारीख वाले अवलोकनों को दर्शाती हैं, उन संगठनों की अंतिम संख्या को नहीं जिनके डेटा चोरी या स्थायी समझौते की पुष्टि हुई है।

वेंडर की सूचनाएँ और मार्गदर्शन

• ConnectWise Trust Center, Cloud Backup incident advisories, आधिकारिक घटना बयान, रोकथाम की कार्रवाइयाँ, प्रभावित सेवाएँ और बहाली के निर्देश।
• ConnectWise Cloud Backup Technical Investigation and Remediation Guide, October 2026, एप्लिकेशन पहचानकर्ता, जाँच का दायरा, प्रमाण सुरक्षित रखना और ग्राहक remediation मार्गदर्शन।

स्वतंत्र जाँच

• Sophos X-Ops, ConnectWise Cloud Backup application abused in cross-tenant token sweep, स्वचालित एप्लिकेशन authentication और Microsoft Graph token अनुरोधों का स्वतंत्र विश्लेषण।
• Huntress, ConnectWise/SkyKick vendor credentials abused in Microsoft 365 attacks, अनधिकृत authentication के अवलोकन, विशेषाधिकार वाले एप्लिकेशन बदलाव, credential persistence और श्रेय तय करने की सीमाएँ।
• Kudelski Security, ConnectWise Cloud Backup vendor credential abuse, स्वतंत्र घटना विश्लेषण और तकनीकी संदर्भ।

Microsoft दस्तावेज़

• Microsoft, Application objects and service principals, application registrations, ग्राहक-tenant service principals और multitenant authorization की व्याख्या।
• Microsoft, Service-principal sign-ins, workload-identity authentication records की व्याख्या।
• Microsoft, Application authorization and resource access, एप्लिकेशन एक्सेस निर्णयों और authorization सीमाओं की व्याख्या।

संभावित एक्सपोज़र की जाँच करने वाले संगठनों को अपने वातावरण के अनुरूप ConnectWise और Microsoft का ताज़ा सुरक्षा मार्गदर्शन अपनाना चाहिए।

TechiesJournal पर संबंधित लेख

• MCP क्रेडेंशियल सीमा: MCP सर्वर को यह क्यों नहीं तय करना चाहिए कि आपके OAuth क्रेडेंशियल कहाँ जाएँ यह देखने के लिए कि एप्लिकेशन credentials पर कहाँ भरोसा करना चाहिए और कहाँ नहीं।
• CI/CD सप्लाई चेन हमले: हमलावर आपकी पाइपलाइन तक कैसे पहुँचते हैं यह देखने के लिए कि भरोसेमंद कनेक्शन कैसे प्रवेश का रास्ता बन सकता है।