एक नकली IT कॉल, फिर बादल का डेटा गायब—UNC6671 का नया हमला

Google Threat Intelligence Group ने 6 अगस्त 2026 को बताया कि UNC6671 निजी मोबाइल पर नकली IT सहायता कॉल करके कर्मचारियों को जाली प्रवेश पृष्ठों तक ले जाता है, प्रमाण और MFA टोकन पकड़ता है तथा वैध सत्र से Microsoft 365 और Okta का डेटा बाहर निकालता है। Google के नए UNC6671 विश्लेषण में गतिविधि को जारी बताया गया है और हालिया निशानों में वित्तीय सेवाएँ, निजी इक्विटी तथा पेशेवर सेवा कंपनियाँ शामिल हैं।

TechCrunch की 6 अगस्त की रिपोर्ट ने भी वित्तीय कंपनियों के कर्मचारियों को फोन करके पहुँच हासिल करने और चुराए गए डेटा के सहारे जबरन वसूली करने वाली गतिविधि का विवरण दिया। खुली रिपोर्टों में किसी भारतीय पीड़ित की पहचान नहीं दी गई है; फिर भी Microsoft 365 या Okta पर निर्भर भारतीय कारोबार के लिए यही पहचान और सहायता-डेस्क कार्यप्रवाह प्रासंगिक जोखिम है। शीर्षक में डेटा “गायब” होने का आशय उसकी अनधिकृत निकासी है—मूल भंडार से हर फाइल मिटा देना नहीं।

निजी फोन से SaaS भंडार तक हमले की कड़ी

कॉल कंपनी के नियंत्रित सहायता माध्यम के बजाय कर्मचारी के निजी नंबर पर आती है। हमलावर स्वयं को आंतरिक सहायता कर्मी बताकर FIDO2 पासकी चालू करने, उसका स्थानांतरण पूरा करने या MFA पंजीकरण बदलने की कथित तात्कालिक जरूरत पैदा करता है। Google ने कुछ हालिया मामलों में वैध सहायता-डेस्क नंबर की नकली कॉलर पहचान दिखाए जाने का भी उल्लेख किया है, इसलिए स्क्रीन पर दिखा नंबर अपने आप में सत्यापन नहीं है।

1. कर्मचारी को संगठन के नाम जैसा दिखने वाला, लेकिन हमलावर के नियंत्रण में मौजूद प्रवेश पृष्ठ खोलने को कहा जाता है।
2. AiTM व्यवस्था उपयोगकर्ता नाम और पासवर्ड पकड़कर उन्हें वास्तविक पहचान प्रदाता को भेजती है। असली सेवा से आई MFA चुनौती को कर्मचारी कथित पंजीकरण प्रक्रिया समझकर पूरा करता है।
3. हमलावर मिले सत्र का उपयोग करता है और स्थायी पहुँच के लिए अपने नियंत्रण वाला नया MFA तरीका पंजीकृत कर सकता है।
4. समझौता हो चुके SSO खाते से SharePoint, OneDrive और जुड़े अनुप्रयोगों की खोज होती है; फिर स्वचालित लिपियाँ उपलब्ध फाइलों को बाहर भेजती हैं।

Google के मई के तकनीकी विवरण में Microsoft Graph, Python और PowerShell से SharePoint तथा OneDrive सामग्री निकालने और वैध सत्र कुकी के जरिए अनुरोधों को सामान्य वेब गतिविधि जैसा दिखाने का वर्णन है। कुछ अनुरोध डाउनलोड के बजाय केवल फाइल-पहुँच घटना के रूप में दर्ज हो सकते हैं, जिससे केवल डाउनलोड चेतावनियों पर निर्भर निगरानी चूक सकती है।

BlackFile नाम गया, UNC6671 की गतिविधि जारी रही

UNC6671 को पहले BlackFile ब्रांड के साथ जोड़ा गया था। मई में BlackFile ने उस नाम से काम बंद करने की घोषणा की, लेकिन Google का नवीनतम आकलन है कि संबंधित गतिविधि Redact, Pink, Helix और Falcon नामों के अंतर्गत जारी रही। यह संबंध समान फिशिंग नमूनों, पीड़ित चयन और साझा अवसंरचना पर आधारित है, केवल मिलते-जुलते नामों पर नहीं।

यह पहचान पूरी तरह निर्णायक नहीं है। ReliaQuest की Helix जाँच ने वॉइस फिशिंग, उपकरण-कोड फिशिंग, नए MFA पंजीकरण और स्वचालित SharePoint निकासी वाला मिलता-जुलता क्रम दर्ज किया, लेकिन Helix को BlackFile का प्रत्यक्ष उत्तराधिकारी मानने के बजाय निकटवर्ती समूह होने की संभावना भी खुली रखी। इसलिए अलग नामों को एक ही संगठन समझने के बजाय साझा कार्यप्रणाली और अवसंरचना को अधिक ठोस संकेत मानना चाहिए।

कर्मचारी कॉल को कहाँ रोक सकता है

इस हमले में निर्णायक क्षण वह है जब कथित सहायता कर्मी पहचान से जुड़ी कार्रवाई करवाना चाहता है। भारतीय IT सहायता प्रक्रिया में स्पष्ट नियम होना चाहिए कि अनचाही कॉल पर पासवर्ड, एकबारगी कोड, MFA स्वीकृति या उपकरण-कोड साझा नहीं किया जाएगा और निजी फोन पर तत्काल पासकी पंजीकरण नहीं कराया जाएगा। यह नियम कर्मचारियों, ठेकेदारों और अधिकारियों सभी पर समान रूप से लागू होना चाहिए।

कर्मचारी की संक्षिप्त प्रतिक्रिया हो सकती है: “मैं इस कॉल पर पहचान संबंधी कोई कार्रवाई नहीं करूँगा। टिकट संख्या बताइए; मैं आधिकारिक सहायता पोर्टल या कंपनी निर्देशिका के नंबर से स्वयं संपर्क करूँगा।” इसके बाद कॉल काटना, संदेश में मिला पता न खोलना और पहले से स्वीकृत माध्यम से सहायता अनुरोध की पुष्टि करना जरूरी है। कॉल करने वाले के बताए नंबर पर वापस फोन करना स्वतंत्र सत्यापन नहीं है।

यदि कर्मचारी ने जाली पृष्ठ पर विवरण भर दिया या MFA चुनौती स्वीकार कर ली है, तो सूचना में घटना का समय, फोन नंबर, खोला गया डोमेन, इस्तेमाल हुआ खाता और पूरी की गई चुनौती शामिल होनी चाहिए। केवल पासवर्ड बदलना पर्याप्त नहीं हो सकता, क्योंकि हमलावर के पास पहले से सक्रिय सत्र या नया पंजीकृत MFA तरीका हो सकता है।

प्रशासक पहले सत्र रोके, फिर निकासी खोजे

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

• Okta या Microsoft Entra ID में विफल अथवा छोड़ी गई MFA चुनौतियों के तुरंत बाद हुए नए प्रमाणीकरण पंजीकरण खोजें।
• अप्रबंधित उपकरणों, आवासीय प्रॉक्सी, असामान्य VPN निकास और उपयोगकर्ता के सामान्य स्थान से अलग प्रवेशों की समीक्षा करें।
• SharePoint और OneDrive में FileDownloaded के साथ FileAccessed घटनाएँ भी देखें, खासकर जब बहुत अधिक फाइलें कम समय में खुलें या उपयोगकर्ता प्रतिनिधि Python अथवा PowerShell जैसी लिपि दिखाए।
• संवेदनशील SaaS सेवाओं तक पहुँच प्रबंधित उपकरणों तक सीमित करें; निष्क्रिय सत्र की अवधि घटाएँ और महत्वपूर्ण संसाधनों पर दोबारा प्रमाणीकरण लागू करें।

फिशिंग-प्रतिरोधी पासकी और सुरक्षा कुंजियाँ उपयोगी हैं, लेकिन इस अभियान में पासकी लागू करने का बहाना ही सामाजिक अभियांत्रिकी का हिस्सा है। इसलिए मजबूत प्रमाणीकरण के साथ सहायता कर्मी की स्वतंत्र पुष्टि, नए पंजीकरण की निगरानी और सत्र-स्तरीय नियंत्रण भी आवश्यक हैं।

अभी पुष्टि हमले के क्रम की है, भारतीय पीड़ित की नहीं

6 अगस्त के अपडेट से यह स्पष्ट है कि UNC6671 से जोड़ी गई गतिविधि जारी है, प्रवेश का प्रमुख रास्ता नकली सहायता कॉल और जाली पहचान पृष्ठ हैं, तथा अंतिम उद्देश्य बादल डेटा निकालकर जबरन वसूली करना है। जुलाई में देखी गई अवसंरचना वित्तीय और कानूनी क्षेत्रों की ओर अधिक केंद्रित थी, पर सार्वजनिक विश्लेषण ने पीड़ित संगठनों के नाम नहीं दिए।

Redact, Pink, Helix और Falcon एक ही समन्वित समूह हैं या साझा साधनों वाले अलग सहयोगी, यह अभी आकलन का विषय है। बचाव के लिए अधिक उपयोगी संकेत नाम नहीं, बल्कि पूरी घटना-श्रृंखला है: निजी फोन पर तत्काल IT अनुरोध, नया MFA पंजीकरण, अप्रबंधित उपकरण से सत्र और उसके बाद SaaS फाइलों की असामान्य सामूहिक पहुँच।