हमला कैसे अंजाम दिया गया: AI टूल्स बने ट्रिगर

इस हमले की नवीनता इसके निष्पादन के तरीके में थी, जिसने पारंपरिक सुरक्षा जांचों को दरकिनार करते हुए डेवलपर टूल्स को ही हमले का हथियार बना दिया।

• प्रवेश बिंदु: यह सेंध एक पहले से कम्प्रोमाइज्ड कंट्रीब्यूटर अकाउंट का उपयोग करके Azure/durabletask रिपॉजिटरी में एक दुर्भावनापूर्ण कमिट को पुश करने से शुरू हुई । पकड़ में आने से बचने के लिए, कमिट का शीर्षक "Switched DataConverter to OrchestrationContext [skip ci]" रखा गया था और इसके मेटाडेटा को मार्च 2020 का बताकर पिछली तारीख का दिखाया गया था ।
• AI असिस्टेंट के ज़रिये पेलोड डिलीवरी: इस कमिट ने पारंपरिक सोर्स कोड में कोई बदलाव नहीं किया। इसके बजाय, इसने कॉन्फ़िगरेशन फ़ाइलें प्लांट कीं, जैसे कि Claude Code, Gemini CLI, और Cursor के लिए सेटिंग्स । जब किसी डेवलपर ने Claude Code, Gemini CLI, Cursor, या Visual Studio Code (VS Code) में संक्रमित रिपॉजिटरी को खोला, तो इन AI टूल्स ने अपने आप कॉन्फ़िगरेशन फ़ाइलों को पढ़ा और एक छिपे हुए क्रेडेंशियल-हार्वेस्टिंग पेलोड को एक्सीक्यूट कर दिया ।
• क्या चुराया गया: एक बार एक्टिवेट होने पर, वर्म ने डेवलपर की मशीन और संबंधित माहौल से कई तरह की अहम साखें चुरा लीं, जिनमें AWS, GCP, Azure, HashiCorp Vault, Kubernetes, और GitHub Actions की क्रेडेंशियल शामिल थीं ।
• स्वतः प्रतिकृति: क्रेडेंशियल चुराने के बाद, वर्म ने पीड़ित की पहुंच वाली अन्य रिपॉजिटरी में वही दुर्भावनापूर्ण कमिट पुश करने के लिए उनका उपयोग किया, जिससे यह कई संगठनों में तेजी से फैलने में सक्षम हो गया ।

उत्पत्ति: Red Hat npm समझौता

माइक्रोसॉफ्ट गिटहब की घटना एक ऐसे अभियान का अंतिम कार्य था जो कुछ दिन पहले ओपन-सोर्स सॉफ्टवेयर सप्लाई चेन में शुरू हुआ था।

1 जून 2026 को, हमलावरों ने एक Red Hat कर्मचारी के चुराए गए गिटहब अकाउंट का उपयोग करके 32 आधिकारिक @redhat-cloud-services npm पैकेजों के बैकडोर वाले संस्करण प्रकाशित किए, जो 90 से अधिक संस्करणों में फैले थे । माइक्रोसॉफ्ट थ्रेट इंटेलिजेंस ने इस समझौते की जड़ RedHatInsights/javascript-clients CI/CD पाइपलाइन में खोज निकाली, जिसने हमलावरों को वैध-दिखने वाले प्रमाणिक हस्ताक्षरों के साथ ट्रोजन-युक्त पैकेज प्रकाशित करने की अनुमति दी । इन दुर्भावनापूर्ण पैकेजों में एक अस्पष्ट प्रीइंस्टॉल स्क्रिप्ट थी जो इंस्टॉलेशन पर क्रेडेंशियल स्टीलर को एक्सीक्यूट करती थी, जिसने व्यापक मियास्मा प्रसार की नींव रखी ।

प्रतिक्रिया और रोकथाम

हमले की प्रतिक्रिया तेज और निर्णायक थी, लेकिन इस घटना के निहितार्थ बहुत गहरे हैं।

• तत्काल डिसेबलमेंट: गिटहब के स्वचालित दुरुपयोग पहचान प्रणाली ने दो अलग-अलग लहरों में सभी 73 संक्रमित रिपॉजिटरी को डिसेबल कर दिया, उनकी सार्वजनिक पहुंच को तुरंत रोक दिया और "सेवा की शर्तों का उल्लंघन" का नोटिस प्रदर्शित किया ।
• रिकवरी और उपचार: माइक्रोसॉफ्ट ने 8 जून तक सभी प्रभावित रिपॉजिटरी को पूरी तरह से रीस्टोर कर दिया और प्रभावित ग्राहकों को सूचित किया । एक मुख्य खोज यह थी कि हमलावर ने पहुंच बनाए रखने और इसे व्यापक करने के लिए अन-रोटेटेड GitHub Actions सीक्रेट्स का पुन: उपयोग किया, जो दर्शाता है कि पिछले समझौते को पूरी तरह से साफ नहीं किया गया था ।
• एक गहरी जड़: जांच से पता चला कि 5 जून के हमले में उपयोग किए गए चुराए गए क्रेडेंशियल हथियार बनाए जाने से 48 दिन पहले से एक्टिव स्टीलर लॉग में पड़े हुए थे, जो एक लंबी अवधि की घुसपैठ को रेखांकित करता है जो वर्म के सक्रिय होने से पहले की थी ।

आरोपण: Shai-Hulud विरासत और नकलची समस्या

मियास्मा Mini Shai-Hulud वर्म फ्रेमवर्क का प्रत्यक्ष वंशज है, जो TeamPCP नामक खतरा समूह द्वारा बनाया गया एक टूलकिट है । TeamPCP का पिछला अभियान, जिसका 12 मई 2026 को खुलासा हुआ था, पहले ही 170 से अधिक npm और PyPI पैकेजों से समझौता कर चुका था, जिनके 518 मिलियन से अधिक संचयी डाउनलोड थे और यह सीधे AI डेवलपर लाइब्रेरी को लक्षित कर रहा था ।

स्थिति और भी जटिल है क्योंकि TeamPCP ने Mini Shai-Hulud फ्रेमवर्क को ओपन-सोर्स कर दिया था । इसका मतलब है कि अज्ञात संख्या में नकलची एक्टर्स के पास एक ही कोडबेस की पहुंच है। जबकि तकनीक और कोड मियास्मा को TeamPCP की वंशावली से मजबूती से जोड़ते हैं, कई सुरक्षा शोधकर्ता आगाह करते हैं कि मूल समूह के लिए एक निश्चित आरोप नहीं लगाया जा सकता है, क्योंकि ओपन-सोर्स टूलकिट वाला कोई भी एक्टर इस विशिष्ट हमले की लहर का हिस्सा या पूरा आयोजन कर सकता था ।

डेवलपर्स के लिए सुरक्षा सिफारिशें

मियास्मा हमला सुरक्षा सीमाओं को मौलिक रूप से फिर से परिभाषित करता है। कोड रिपॉजिटरी खोलना अब एक निष्क्रिय, सुरक्षित कार्रवाई नहीं रह गई है। शोधकर्ताओं ने कई प्रमुख सिफारिशों पर सहमति जताई है:

• सब कुछ रद्द करें और रोटेट करें: सभी GitHub Actions टोकन, क्लाउड प्रदाता क्रेडेंशियल, npm पब्लिश टोकन, और ऐसे किसी भी अन्य सीक्रेट को तुरंत रोटेट करें जो CI/CD लॉग, संक्रमित रिपॉजिटरी, या स्टीलर लॉग के माध्यम से उजागर हो सकते हैं ।
• सख्त MFA लागू करें: क्रेडेंशियल-आधारित घुसपैठ को रोकने के लिए सभी योगदानकर्ता खातों के लिए बहु-कारक प्रमाणीकरण, विशेष रूप से हार्डवेयर सुरक्षा कुंजियों का उपयोग करना अनिवार्य करें ।
• AI टूलिंग की विश्वास सीमाओं को साफ करें: अविश्वसनीय रिपॉजिटरी को वैसे ही समझें जैसे एक अनजान बाइनरी को। AI कोडिंग एजेंट्स (Claude Code, Cursor, Gemini CLI, VS Code) को कॉन्फ़िगर करें कि वे रिपॉजिटरी से कॉन्फ़िगरेशन फ़ाइलों और कार्यों को अपने आप न चलाएं या पढ़ें ।
• CI/CD पाइपलाइनों को मजबूत करें: GitHub Actions वर्कफ़्लो का ऑडिट करें, Actions टोकन पर राइट एक्सेस को प्रतिबंधित करें, अप्रयुक्त टोकन हटाएं, और अल्पकालिक क्रेडेंशियल्स के उपयोग को लागू करें ।
• सप्लाई चेन स्वच्छता को मजबूत करें: डिपेंडेंसी स्कैनिंग टूल का उपयोग करें, एक SBOM (सॉफ्टवेयर बिल ऑफ मैटेरियल्स) तैयार करें, और इंस्टॉलेशन से पहले पैकेज प्रोवेनेंस (उत्पत्ति) को सत्यापित करें। अस्पष्ट प्रीइंस्टॉल या पोस्टइंस्टॉल स्क्रिप्ट के लिए पैकेजों की निगरानी करें ।

हमला कैसे अंजाम दिया गया: AI टूल्स बने ट्रिगर

इस हमले की नवीनता इसके निष्पादन के तरीके में थी, जिसने पारंपरिक सुरक्षा जांचों को दरकिनार करते हुए डेवलपर टूल्स को ही हमले का हथियार बना दिया।

• प्रवेश बिंदु: यह सेंध एक पहले से कम्प्रोमाइज्ड कंट्रीब्यूटर अकाउंट का उपयोग करके Azure/durabletask रिपॉजिटरी में एक दुर्भावनापूर्ण कमिट को पुश करने से शुरू हुई । पकड़ में आने से बचने के लिए, कमिट का शीर्षक "Switched DataConverter to OrchestrationContext [skip ci]" रखा गया था और इसके मेटाडेटा को मार्च 2020 का बताकर पिछली तारीख का दिखाया गया था ।
• AI असिस्टेंट के ज़रिये पेलोड डिलीवरी: इस कमिट ने पारंपरिक सोर्स कोड में कोई बदलाव नहीं किया। इसके बजाय, इसने कॉन्फ़िगरेशन फ़ाइलें प्लांट कीं, जैसे कि Claude Code, Gemini CLI, और Cursor के लिए सेटिंग्स । जब किसी डेवलपर ने Claude Code, Gemini CLI, Cursor, या Visual Studio Code (VS Code) में संक्रमित रिपॉजिटरी को खोला, तो इन AI टूल्स ने अपने आप कॉन्फ़िगरेशन फ़ाइलों को पढ़ा और एक छिपे हुए क्रेडेंशियल-हार्वेस्टिंग पेलोड को एक्सीक्यूट कर दिया ।
• क्या चुराया गया: एक बार एक्टिवेट होने पर, वर्म ने डेवलपर की मशीन और संबंधित माहौल से कई तरह की अहम साखें चुरा लीं, जिनमें AWS, GCP, Azure, HashiCorp Vault, Kubernetes, और GitHub Actions की क्रेडेंशियल शामिल थीं ।
• स्वतः प्रतिकृति: क्रेडेंशियल चुराने के बाद, वर्म ने पीड़ित की पहुंच वाली अन्य रिपॉजिटरी में वही दुर्भावनापूर्ण कमिट पुश करने के लिए उनका उपयोग किया, जिससे यह कई संगठनों में तेजी से फैलने में सक्षम हो गया ।

उत्पत्ति: Red Hat npm समझौता

माइक्रोसॉफ्ट गिटहब की घटना एक ऐसे अभियान का अंतिम कार्य था जो कुछ दिन पहले ओपन-सोर्स सॉफ्टवेयर सप्लाई चेन में शुरू हुआ था।

1 जून 2026 को, हमलावरों ने एक Red Hat कर्मचारी के चुराए गए गिटहब अकाउंट का उपयोग करके 32 आधिकारिक @redhat-cloud-services npm पैकेजों के बैकडोर वाले संस्करण प्रकाशित किए, जो 90 से अधिक संस्करणों में फैले थे । माइक्रोसॉफ्ट थ्रेट इंटेलिजेंस ने इस समझौते की जड़ RedHatInsights/javascript-clients CI/CD पाइपलाइन में खोज निकाली, जिसने हमलावरों को वैध-दिखने वाले प्रमाणिक हस्ताक्षरों के साथ ट्रोजन-युक्त पैकेज प्रकाशित करने की अनुमति दी । इन दुर्भावनापूर्ण पैकेजों में एक अस्पष्ट प्रीइंस्टॉल स्क्रिप्ट थी जो इंस्टॉलेशन पर क्रेडेंशियल स्टीलर को एक्सीक्यूट करती थी, जिसने व्यापक मियास्मा प्रसार की नींव रखी ।

प्रतिक्रिया और रोकथाम

हमले की प्रतिक्रिया तेज और निर्णायक थी, लेकिन इस घटना के निहितार्थ बहुत गहरे हैं।

• तत्काल डिसेबलमेंट: गिटहब के स्वचालित दुरुपयोग पहचान प्रणाली ने दो अलग-अलग लहरों में सभी 73 संक्रमित रिपॉजिटरी को डिसेबल कर दिया, उनकी सार्वजनिक पहुंच को तुरंत रोक दिया और "सेवा की शर्तों का उल्लंघन" का नोटिस प्रदर्शित किया ।
• रिकवरी और उपचार: माइक्रोसॉफ्ट ने 8 जून तक सभी प्रभावित रिपॉजिटरी को पूरी तरह से रीस्टोर कर दिया और प्रभावित ग्राहकों को सूचित किया । एक मुख्य खोज यह थी कि हमलावर ने पहुंच बनाए रखने और इसे व्यापक करने के लिए अन-रोटेटेड GitHub Actions सीक्रेट्स का पुन: उपयोग किया, जो दर्शाता है कि पिछले समझौते को पूरी तरह से साफ नहीं किया गया था ।
• एक गहरी जड़: जांच से पता चला कि 5 जून के हमले में उपयोग किए गए चुराए गए क्रेडेंशियल हथियार बनाए जाने से 48 दिन पहले से एक्टिव स्टीलर लॉग में पड़े हुए थे, जो एक लंबी अवधि की घुसपैठ को रेखांकित करता है जो वर्म के सक्रिय होने से पहले की थी ।

आरोपण: Shai-Hulud विरासत और नकलची समस्या

मियास्मा Mini Shai-Hulud वर्म फ्रेमवर्क का प्रत्यक्ष वंशज है, जो TeamPCP नामक खतरा समूह द्वारा बनाया गया एक टूलकिट है । TeamPCP का पिछला अभियान, जिसका 12 मई 2026 को खुलासा हुआ था, पहले ही 170 से अधिक npm और PyPI पैकेजों से समझौता कर चुका था, जिनके 518 मिलियन से अधिक संचयी डाउनलोड थे और यह सीधे AI डेवलपर लाइब्रेरी को लक्षित कर रहा था ।

स्थिति और भी जटिल है क्योंकि TeamPCP ने Mini Shai-Hulud फ्रेमवर्क को ओपन-सोर्स कर दिया था । इसका मतलब है कि अज्ञात संख्या में नकलची एक्टर्स के पास एक ही कोडबेस की पहुंच है। जबकि तकनीक और कोड मियास्मा को TeamPCP की वंशावली से मजबूती से जोड़ते हैं, कई सुरक्षा शोधकर्ता आगाह करते हैं कि मूल समूह के लिए एक निश्चित आरोप नहीं लगाया जा सकता है, क्योंकि ओपन-सोर्स टूलकिट वाला कोई भी एक्टर इस विशिष्ट हमले की लहर का हिस्सा या पूरा आयोजन कर सकता था ।

डेवलपर्स के लिए सुरक्षा सिफारिशें

मियास्मा हमला सुरक्षा सीमाओं को मौलिक रूप से फिर से परिभाषित करता है। कोड रिपॉजिटरी खोलना अब एक निष्क्रिय, सुरक्षित कार्रवाई नहीं रह गई है। शोधकर्ताओं ने कई प्रमुख सिफारिशों पर सहमति जताई है:

• सब कुछ रद्द करें और रोटेट करें: सभी GitHub Actions टोकन, क्लाउड प्रदाता क्रेडेंशियल, npm पब्लिश टोकन, और ऐसे किसी भी अन्य सीक्रेट को तुरंत रोटेट करें जो CI/CD लॉग, संक्रमित रिपॉजिटरी, या स्टीलर लॉग के माध्यम से उजागर हो सकते हैं ।
• सख्त MFA लागू करें: क्रेडेंशियल-आधारित घुसपैठ को रोकने के लिए सभी योगदानकर्ता खातों के लिए बहु-कारक प्रमाणीकरण, विशेष रूप से हार्डवेयर सुरक्षा कुंजियों का उपयोग करना अनिवार्य करें ।
• AI टूलिंग की विश्वास सीमाओं को साफ करें: अविश्वसनीय रिपॉजिटरी को वैसे ही समझें जैसे एक अनजान बाइनरी को। AI कोडिंग एजेंट्स (Claude Code, Cursor, Gemini CLI, VS Code) को कॉन्फ़िगर करें कि वे रिपॉजिटरी से कॉन्फ़िगरेशन फ़ाइलों और कार्यों को अपने आप न चलाएं या पढ़ें ।
• CI/CD पाइपलाइनों को मजबूत करें: GitHub Actions वर्कफ़्लो का ऑडिट करें, Actions टोकन पर राइट एक्सेस को प्रतिबंधित करें, अप्रयुक्त टोकन हटाएं, और अल्पकालिक क्रेडेंशियल्स के उपयोग को लागू करें ।
• सप्लाई चेन स्वच्छता को मजबूत करें: डिपेंडेंसी स्कैनिंग टूल का उपयोग करें, एक SBOM (सॉफ्टवेयर बिल ऑफ मैटेरियल्स) तैयार करें, और इंस्टॉलेशन से पहले पैकेज प्रोवेनेंस (उत्पत्ति) को सत्यापित करें। अस्पष्ट प्रीइंस्टॉल या पोस्टइंस्टॉल स्क्रिप्ट के लिए पैकेजों की निगरानी करें ।