Axios npm हमला और नकली Claude ऐप्स ने सॉफ्टवेयर-ट्रस्ट की नई समस्या उजागर की

प्रभावित संस्करण करीब तीन घंटे तक उपलब्ध रहे। Google Threat Intelligence Group ने 31 मार्च को 00:21 से 03:20 UTC के बीच गतिविधि दर्ज की, जबकि अन्य रिपोर्टों में भी लगभग दो से तीन घंटे की अवधि बताई गई है। Axios एक बेहद प्रभावशाली डिपेंडेंसी है। अलग-अलग स्रोत इसके npm डाउनलोड का अनुमान हर सप्ताह लगभग 8 करोड़ से लेकर 10 करोड़ से अधिक तक लगाते हैं, हालांकि आंकड़ों में अंतर है।

मेंटेनर अकाउंट का दुरुपयोग कैसे हुआ

सार्वजनिक रिपोर्टिंग से सबसे मजबूत निष्कर्ष यही निकलता है कि यह Axios की मूल लाइब्रेरी में मौजूद खामी नहीं, बल्कि npm अकाउंट या प्रकाशन-क्रेडेंशियल के कब्जे का मामला था। एक रिपोर्ट के अनुसार हमलावरों ने प्रमुख मेंटेनर के लंबे समय तक इस्तेमाल होने वाले npm एक्सेस टोकन का दुरुपयोग किया; अन्य रिपोर्टें इसे सामान्य रूप से मेंटेनर अकाउंट या प्रकाशन क्रेडेंशियल के समझौते के रूप में वर्णित करती हैं।

यह अंतर महत्वपूर्ण है। हमले ने मेंटेनर के प्रकाशन-अधिकार और npm की रिलीज पाइपलाइन के बीच मौजूद भरोसे की सीमा को निशाना बनाया। चूंकि संक्रमित रिलीज एक वैध अकाउंट के जरिए प्रकाशित हुई थीं, इसलिए डेवलपर और स्वचालित सिस्टम उन्हें संदिग्ध मानने की कम वजह रखते थे।

दुर्भावनापूर्ण डिपेंडेंसी ने क्या किया

plain-crypto-js@4.2.1 को सामान्य पैकेज डिपेंडेंसी जैसा दिखाया गया, लेकिन इसका वास्तविक उद्देश्य postinstall स्क्रिप्ट चलाना था। यह स्क्रिप्ट कमांड-एंड-कंट्रोल सर्वर से जुड़ी और होस्ट ऑपरेटिंग सिस्टम के अनुसार दूसरे चरण का पेलोड डाउनलोड किया।

इस हमले में डेवलपर को कोई साफ तौर पर संदिग्ध executable डाउनलोड करने की जरूरत नहीं थी। सामान्य डिपेंडेंसी अपडेट, CI बिल्ड या जोखिम वाली अवधि में अपने-आप चलने वाला

npm install

क्या BlueNoroff जिम्मेदार था?

उपलब्ध सामग्री के आधार पर हमले का attribution यानी जिम्मेदारी तय नहीं है। कुछ रिपोर्टें इस अभियान को उत्तर कोरिया से जुड़े समूहों, जिनमें BlueNoroff या उससे संबंधित क्लस्टर शामिल हैं, से जोड़ती हैं। वहीं Microsoft ने इसे Sapphire Sleet से जोड़ा है।

इन आकलनों को एक ही पक्के निष्कर्ष के रूप में पेश नहीं किया जाना चाहिए। कोड, इंफ्रास्ट्रक्चर और संचालन के तौर-तरीकों में समानता attribution का संकेत दे सकती है, लेकिन अकेले इससे यह साबित नहीं होता कि हमला किस समूह ने किया। सार्वजनिक जानकारी के आधार पर सुरक्षित निष्कर्ष यह है कि Axios समझौते में मेंटेनर अकाउंट का कब्जा, संक्रमित रिलीज और क्रॉस-प्लेटफॉर्म RAT शामिल था; हमलावर की पहचान पर अलग-अलग आकलन मौजूद हैं।

SilverFox ने नकली Claude ऐप्स का इस्तेमाल कैसे किया

SilverFox ने संगठनों तक पहुंचने के लिए अलग रास्ता अपनाया और Windows, macOS तथा Linux के लिए नकली Claude ऐप वितरित किए। इस अभियान में भारत, इंडोनेशिया, दक्षिण अफ्रीका और रूस के औद्योगिक, कंसल्टिंग, व्यापार तथा परिवहन क्षेत्रों के संगठनों को निशाना बनाया गया।

ये Anthropic के Claude ब्रांड की नकल करने वाले ऐप थे, आधिकारिक Claude इंस्टॉलर नहीं। इनकी ताकत एक विश्वसनीय कार्यस्थलीय स्थिति में थी: कोई कर्मचारी AI उत्पादकता टूल खोजता है, परिचित नाम वाला ऐप डाउनलोड करता है और असल में मैलवेयर इंस्टॉल कर लेता है। Kaspersky की रिपोर्टिंग के अनुसार यह अभियान SilverFox की उन गतिविधियों का हिस्सा है, जिनकी कई लहरें दिसंबर 2025 से देखी गई हैं।

टैक्स-आधारित फिशिंग से AI वाले लालच तक

इस अभियान की पृष्ठभूमि पहले के टैक्स-थीम वाले फिशिंग हमलों में भी दिखाई देती है। जनवरी और फरवरी 2026 में शोधकर्ताओं ने 1,600 से अधिक दुर्भावनापूर्ण ईमेल दर्ज किए, जो आधिकारिक टैक्स ऑडिट नोटिस होने का दावा करते थे या उनमें टैक्स उल्लंघनों की सूची होने की बात कही गई थी।

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

SilverFox ने चरणबद्ध डिलीवरी मॉडल अपनाया और घुसपैठ के अलग-अलग चरणों के लिए अलग इंफ्रास्ट्रक्चर इस्तेमाल किया। इससे सुरक्षा टीमों के लिए एक ही डोमेन या संकेतक के आधार पर पूरे हमले की कड़ी पहचान करना और उसे ब्लॉक करना कठिन हो सकता है।

साझा सबक: भरोसा भी अटैक सरफेस है

Axios और SilverFox ने अलग-अलग भरोसे के रिश्तों को निशाना बनाया:

• मेंटेनर पर भरोसा: Axios रिलीज अधिकृत npm प्रकाशक के जरिए आई हुई दिखीं।
• डिपेंडेंसी पर भरोसा: पैकेज मैनेजर ने दुर्भावनापूर्ण डिपेंडेंसी को सामान्य इंस्टॉलेशन प्रक्रिया का हिस्सा माना।
• ब्रांड पर भरोसा: नकली Claude इंस्टॉलर ने पहचाने जाने वाले AI उत्पाद की पहचान उधार ली।
• वर्कफ्लो पर भरोसा: डेवलपर और कर्मचारी रोजमर्रा की कार्रवाइयां कर रहे थे—डिपेंडेंसी अपडेट करना या उत्पादकता सॉफ्टवेयर इंस्टॉल करना।

Axios मामला बताता है कि कम समय की exposure window भी खतरनाक हो सकती है। पैकेज इंस्टॉलेशन और CI जॉब अपने-आप चल सकते हैं, इसलिए प्रभावित सिस्टमों की संख्या केवल उन लोगों तक सीमित नहीं रहती जो रिलीज को मैन्युअली जांचते हैं। SilverFox का मामला इसी सिद्धांत को एंडपॉइंट स्तर पर दिखाता है: तेजी से लोकप्रिय हो रहे सॉफ्टवेयर वर्ग हमलावरों को विश्वसनीय नए लालच देते हैं।

संगठनों को अब क्या करना चाहिए

Axios मामले में लॉकफाइल, पैकेज मैनिफेस्ट, बिल्ड लॉग, कैश, डिपेंडेंसी इन्वेंटरी और संबंधित सिस्टमों में axios@1.14.1, axios@0.30.4 तथा plain-crypto-js@4.2.1 की जांच करें। जिस मशीन ने exposure window के दौरान प्रभावित संस्करण इंस्टॉल किया हो, वहां डाउनलोड किए गए पेलोड, अनधिकृत persistence और उजागर क्रेडेंशियल की जांच की जानी चाहिए। सुरक्षा सलाहें प्रभावित इंस्टॉलेशन को संभावित रूप से संक्रमित मानने की सिफारिश करती हैं।

AI सॉफ्टवेयर के लिए कर्मचारियों को केवल स्वीकृत चैनलों से डेस्कटॉप ऐप डाउनलोड करने दें। प्रकाशक और डाउनलोड डोमेन की पुष्टि करें तथा गैर-स्वीकृत इंस्टॉलर को ब्लॉक या क्वारंटीन करें। npm प्रकाशन के मामले में phishing-resistant MFA, कम अवधि वाले या सीमित-अधिकार क्रेडेंशियल, रिलीज provenance, लॉकफाइल और डिपेंडेंसी बदलावों की समीक्षा जैसे उपाय यह जोखिम घटा सकते हैं कि एक समझौता किया गया अकाउंट पूरे सप्लाई-चेन हमले में बदल जाए।

सबसे व्यापक नियंत्रण हर भरोसे की सीमा पर सत्यापन है। किसी परिचित पैकेज नाम का मतलब यह नहीं कि उसकी हर रिलीज सुरक्षित है। उसी तरह किसी परिचित उत्पाद नाम का मतलब यह भी नहीं कि हर इंस्टॉलर असली है।