लेख में वर्णित token replay का चित्र: MFA से मंज़ूर sign-in, उसके बाद का session token, और Huntress की रिपोर्ट के अनुसार लगभग 10 हफ़्तों तक हमलावर द्वारा उस token का दोबारा इस्तेमाल। यह वैचारिक है, असली लॉग या स्क्रीनशॉट नहीं।
हमलावरों ने वे सेशन चुरा लिए जो MFA पहले ही पार कर चुके थे, उन्हें किराये के सर्वरों से दोबारा चलाया, और फिर पीड़ितों के MFA तरीके बदल दिए। यह कैसे काम करता है और क्या जाँचना चाहिए, यहाँ बताया गया है।
जो सेशन MFA पहले ही पार कर चुका है, उसे दोबारा MFA नहीं चाहिए
अगर हमलावर वह सेशन चुरा ले जिसे multifactor authentication ने अभी-अभी मंज़ूर किया है, तो MFA के पास जाँचने को कुछ बचता ही नहीं।
सुरक्षा कंपनी Huntress ने Microsoft 365 खातों पर हुए एक अभियान की रिपोर्ट में यही बताया है। 14 July से 22 September 2026 के बीच उसने अपने ग्राहकों के परिवेशों में 200,000 से ज़्यादा विफल sign-in प्रयास और कम से कम 497 सफल प्रयास देखे। इस गतिविधि ने 79 संगठनों को छुआ।
यह लेख उनके लिए है जो Microsoft 365 चलाते या उसे सहारा देते हैं: administrators, सुरक्षा कर्मचारी और IT प्रबंधक। यह समझाता है कि token क्या है, हमलावरों ने उन्हें कैसे लिया, इसके बाद उन्होंने क्या किया, और Microsoft के कौन से नियंत्रण मदद करते हैं। यह यह भी बताता है कि वे नियंत्रण कहाँ रुक जाते हैं, क्योंकि वह हिस्सा आसानी से छूट जाता है।
token क्या है और replay का मतलब क्या है
जब आप Microsoft 365 में sign in करते हैं, तो आप पासवर्ड और दूसरे factor से साबित करते हैं कि आप कौन हैं। फिर Microsoft आपके डिवाइस को एक token देता है, जो एक छोटा डिजिटल पास है और कहता है “इस उपयोगकर्ता की जाँच हो चुकी है।” हर क्लिक पर sign in न करना पड़े, इसलिए आपके apps वह पास Exchange, SharePoint और Teams को दिखाते हैं।
token replay का मतलब है किसी और का पास इस्तेमाल करना। अगर हमलावर कोई वैध token कॉपी करके दूसरी मशीन से पेश कर दे, तो सेवा को असली दिखने वाला पास दिखता है। पासवर्ड और दूसरे factor की जाँच पहले ही हो चुकी है, इसलिए उन्हें दोबारा नहीं माँगा जाता।
इसीलिए यह हमला देखना कठिन है। कुछ अंदाज़े से नहीं आज़माया गया और सफल sign-in में कुछ विफल नहीं हुआ। पास बस ग़लत व्यक्ति ने इस्तेमाल किया।
Huntress ने क्या देखा
Huntress के अनुसार अभियान लगभग दस हफ़्ते चला। ऊपर की गिनतियों के अलावा, उसे पीड़ितों की Entra directories में पंजीकृत 48 नकली डिवाइस मिले। कम से कम 19 संगठनों में पीड़ितों के मौजूदा MFA तरीके हटा दिए गए और पहले sign-in के तीन घंटे के भीतर नए जोड़ दिए गए।
हमलावरों ने दो स्तरों में काम किया। सर्वरों के एक समूह ने पीड़ितों से सेशन पकड़े। एक जर्मन hosting provider की address range के किराये के सर्वरों के अलग समूह ने उन सेशनों को दोबारा चलाया। password spraying से तुलना करते हुए Huntress replay चरण को token spraying कहता है।
दोनों स्तर अलग हैं, इसलिए एक को रोकने से दूसरा नहीं रुकता।
गति मायने रखती थी। Huntress ने 21 July को MFA prompt और हाइजैक हुए सेशन के बीच 12 मिनट, और 22 September को चार मिनट मापे। 26 October को इन निष्कर्षों की रिपोर्ट करने वाला The Hacker News किसी threat actor का नाम नहीं बताता, और Huntress भी नहीं बताता। कहीं और दिखने वाले किसी भी आरोपण को अपुष्ट मानें।
संख्याओं पर एक टिप्पणी: वे केवल Huntress के ग्राहक परिवेशों से आती हैं। असली पैमाना कम से कम इतना है, और शायद इससे बड़ा। एक ही September विस्फोट के लिए Huntress का पृष्ठ दो अलग आँकड़े भी देता है, इसलिए हम उनमें से किसी को उद्धृत नहीं करते।
हमलावरों को token कैसे मिले
Huntress और The Hacker News तीन रास्ते बताते हैं।
पहला adversary-in-the-middle phishing है, संक्षेप में AiTM। पीड़ित एक नकली sign-in पृष्ठ पर पहुँचता है जो उसके और असली Microsoft पृष्ठ के बीच बैठा होता है। वह उनका पासवर्ड और MFA कोड Microsoft तक पहुँचा देता है, और लौटने वाला token अपने पास रख लेता है।
पीड़ित को सामान्य sign-in दिखता है। हमलावर के हाथ में चालू सेशन होता है।
दूसरा device code phishing है। TV या command-line टूल जैसे कुछ डिवाइस पूरा sign-in पृष्ठ नहीं दिखा सकते, इसलिए Microsoft उन्हें एक छोटा कोड दिखाकर sign in करने देता है, जिसे उपयोगकर्ता दूसरे डिवाइस पर डालता है। हमलावर वह प्रक्रिया शुरू करके, विश्वसनीय कहानी के साथ पीड़ित को कोड भेज सकता है, और पीड़ित के मंज़ूर करते ही token पा लेता है।
तीसरा वैध sign-in के दौरान सीधा social engineering है। रिपोर्टें इस पर कम ब्योरा देती हैं, इसलिए हमें नहीं पता कि व्यवहार में यह कैसे काम किया।
अंदर पहुँचने के बाद हमलावरों ने क्या किया
पहले replay के बाद Huntress को एक सुसंगत पैटर्न मिला। हमलावरों ने अपना authenticator app जोड़ा, या पीड़ित के MFA तरीके मिटाकर नया पंजीकृत किया। 21 July की एक घटना में हमलावर द्वारा जोड़ा गया “iPhone 13” नाम का तरीका रिले द्वारा सेशन पकड़े जाने के लगभग 50 मिनट बाद सक्रिय हो गया।
उन्होंने Entra में नकली डिवाइस भी पंजीकृत किए, जो किसी के हटाने तक directory में बने रहते हैं। उन्होंने एक बिंदु या “sss” जैसे नामों वाले छिपे inbox rules भी बनाए, जो payroll, जमा और बोनस से जुड़ी मेल को खिसका या मिटा देते थे। एक घटना में हमलावर ने बाहरी अकाउंटेंट को payroll के बारे में ईमेल किया और जवाब छिपा दिए, जो business email compromise का पैटर्न है। दूसरी में Entra ID Protection द्वारा खाते को उच्च जोखिम चिह्नित करने तक एक mailbox से सैकड़ों बाहरी प्राप्तकर्ताओं को स्पैम भेजा गया।
हर क़दम घुसपैठिए को हटाना कठिन बनाता है। नया MFA तरीका यानी हमलावर बाद में फिर sign in कर सकता है। नकली डिवाइस भी यही करता है। छिपा rule पीड़ित को जवाब देखने से रोकता है।
अकेला MFA पर्याप्त क्यों नहीं था
MFA sign-in के क्षण की रक्षा करता है। AiTM हमले में वह काम पीड़ित हमलावर के लिए कर देता है। असली कोड हमलावर के रिले से होकर असली Microsoft सेवा तक जाता है, और नतीजा हमलावर रख लेता है।
कुछ MFA तरीके दूसरों से बेहतर टिकते हैं। authentication strengths पर Microsoft के दस्तावेज़ Windows Hello for Business, FIDO2 security keys और certificate-based authentication को “phishing-resistant” समूह में रखते हैं। वह इन्हें ऐसे तरीकों के रूप में परिभाषित करता है जिनमें तरीके और sign-in सतह के बीच संपर्क ज़रूरी है। Microsoft Authenticator phone sign-in एक passwordless तरीका है पर उस समूह में नहीं है, और कोड तथा push स्वीकृतियाँ दोनों में से किसी में नहीं हैं।
उस परिभाषा की हमारी समझ यह है कि जो रिले पृष्ठ असली sign-in सतह नहीं है, उसे ये तरीके पूरे करने में बहुत कठिनाई होती है। वह हमारा अनुमान है, AiTM पर Microsoft का कथन नहीं, क्योंकि Microsoft का पृष्ठ AiTM का ज़िक्र ही नहीं करता। हमें यह भी नहीं पता कि Huntress के पीड़ित कौन से MFA तरीके इस्तेमाल कर रहे थे, इसलिए हम नहीं कह सकते कि phishing-resistant तरीके इस अभियान को रोक पाते या नहीं।
Microsoft के नियंत्रण क्या ढकते हैं और कहाँ रुकते हैं
token चोरी के विरुद्ध कई नियंत्रण मदद करते हैं। उनमें से कोई अकेला पूरा जवाब नहीं है। Microsoft के मौजूदा दस्तावेज़ों के अनुसार हर एक क्या करता है, और कौन सी सीमा मायने रखती है, यह तालिका बताती है।
| नियंत्रण | यह क्या करता है | जानने योग्य सीमा |
|---|---|---|
| Phishing-resistant authentication strengths | चुने हुए sign-in के लिए FIDO2 keys, Windows Hello for Business या certificate-based authentication अनिवार्य करता है। | Conditional Access का मूल्यांकन पहले authentication चरण के बाद होता है, इसलिए शर्त लागू होने से पहले उपयोगकर्ता फिर भी पासवर्ड टाइप कर सकता है। |
| Token protection | sign-in सेशन tokens को डिवाइस से बाँधता है, इसलिए चुराया गया token दूसरे डिवाइस से नहीं चलना चाहिए। Microsoft कहता है कि यह replay को “घटाने का प्रयास करता है”। | समर्थित प्लैटफ़ॉर्म पर Exchange Online, SharePoint Online और Teams जैसे चुने हुए native apps को ढकता है। ब्राउज़र समर्थन preview में है और Azure Resource Manager तक पहुँचने वाले चुने हुए web apps तक सीमित है। हर प्लैटफ़ॉर्म की मौजूदा स्थिति के लिए पृष्ठ देखें। |
| Continuous access evaluation | password reset, निष्क्रिय किए गए खाते, रद्द किए सेशन या उच्च उपयोगकर्ता जोखिम जैसी घटनाओं के बाद, समाप्त होने से पहले ही Exchange, SharePoint और Teams को token अस्वीकार करने देता है। | केवल समर्थित apps के साथ काम करता है। स्थान जाँचें केवल IP आधारित named locations को ढकती हैं। Microsoft बताता है कि घटना में 15 मिनट तक की देरी हो सकती है। |
| Block device code flow | एक Conditional Access नीति जो उन उपयोगकर्ताओं के लिए device code sign-in रास्ता रोकती है जिन्हें उसकी ज़रूरत नहीं। | Microsoft पहले मौजूदा उपयोग का ऑडिट करने की सलाह देता है, और जिन खातों को आप बाहर रखते हैं वे नीति को लाँघ जाते हैं। Service principals को उपयोगकर्ता नीतियाँ नहीं ढकतीं। |
Microsoft के पृष्ठ के अनुसार Outlook on the web या SharePoint के ब्राउज़र आधारित सेशन token protection की सूची में नहीं हैं। हमारा अनुमान है कि यह AiTM हमलों के लिए एक खाई है, क्योंकि वे आम तौर पर ब्राउज़र सेशन पकड़ते हैं। Microsoft का पृष्ठ ऐसा नहीं कहता, इसलिए इसे तथ्य नहीं, बल्कि अपने tenant में परखने की बात मानें।
Huntress ऐसी Conditional Access नीतियाँ भी सुझाता है जो सभी उपयोगकर्ताओं, सभी cloud apps और सभी client app प्रकारों के लिए MFA अनिवार्य करें या पहुँच रोकें, बिना शर्त। वह विक्रेता की सलाह है, और आधार रेखा के रूप में सही बैठती है। वह ऊपर के नियंत्रणों की जगह नहीं लेती।
चुराए सेशन का शक हो तो क्या करें
एक बात पर Huntress स्पष्ट है। अकेला password reset पर्याप्त नहीं है। हमलावर के MFA तरीके और नकली डिवाइस बने रहते हैं, और access token समाप्त होने तक चलता रह सकता है, जिसे Huntress लगभग 90 मिनट बताता है (Microsoft का डिफ़ॉल्ट 60 से 90 मिनट है)। इन चरणों को क्रम से पूरा करें।
- उपयोगकर्ता के सेशन रद्द करें और फिर पासवर्ड रीसेट करें। अभियान में, पासवर्ड बदलने जैसे कारणों से जो सेशन अब वैध नहीं रहे थे, उन्हें दोबारा चलाने की हमलावर की बाद की कोशिशें Microsoft की “SsoArtifactRevoked” त्रुटि (AADSTS50133) के साथ विफल रहीं।
- उपयोगकर्ता के MFA तरीकों की समीक्षा करें। sign-in के जल्द बाद, ख़ासकर कुछ घंटों के भीतर, जोड़े या मिटाए गए तरीके देखें।
- Entra में पंजीकृत डिवाइसों का ऑडिट करें। डिवाइस हटाने से पहले पक्का करें कि वह वैध नहीं है। Huntress ने नोट किया कि नकली डिवाइसों के नाम “DESKTOP-” से शुरू होकर आठ hex अक्षरों वाले थे, जो Windows के डिफ़ॉल्ट से अलग है, और वह आठ hex अक्षरों वाले “Device-” तथा “Work Pc” उपसर्ग भी सूचीबद्ध करता है।
- Inbox rules और नए enterprise applications जाँचें। छोटे या केवल विराम-चिह्न वाले नाम, और payroll या बैंकिंग संदेशों को छूने वाले rules पर ग़ौर करना चाहिए।
- बाहरी असर देखें। बाहरी पक्षों को भेजी गई मेल और मंज़ूर या बदले गए भुगतान विवरण जाँचें।
threat hunting के लिए Huntress अपने देखे ठीक-ठीक sign-in पैटर्न, client IDs और addresses सूचीबद्ध करता है। उनके लिए उसकी रिपोर्ट इस्तेमाल करें, क्योंकि वे जल्दी बदलते हैं और आम पाठकों से ज़्यादा hunt टीमों के काम आते हैं।
हम क्या जानते हैं और क्या नहीं
| लेबल | कथन |
|---|---|
| तथ्य | Huntress 14 July से 22 September 2026 तक की गतिविधि, अपने ग्राहकों में कम से कम 497 सफल sign-in और 48 नकली Entra डिवाइस रिपोर्ट करता है। |
| शोधकर्ताओं की रिपोर्ट | हमलावरों ने tokens पाने के लिए AiTM रिले, device code phishing और social engineering इस्तेमाल किए, फिर उन्हें किराये के सर्वरों से दोबारा चलाया। |
| शोधकर्ताओं की रिपोर्ट | कम से कम 19 संगठनों में पहले sign-in के तीन घंटे के भीतर MFA तरीके बदल दिए गए। |
| हमारा अनुमान | Phishing-resistant तरीके और डिवाइस से बँधे tokens इस हमले की क़ीमत बढ़ाते हैं। token protection चालू होने पर भी ब्राउज़र सेशन AiTM के लिए खुले रह सकते हैं। |
| अज्ञात | अभियान किसने चलाया। क्या किसी पीड़ित ने phishing-resistant MFA इस्तेमाल किया। Huntress की नज़र से बाहर कितने संगठन प्रभावित हुए। अभियान पर Microsoft का अपना आकलन। |
इसे कितनी गहराई से सीखना चाहिए?
जानें: हर Microsoft 365 उपयोगकर्ता और प्रबंधक को एक विचार समझना चाहिए। MFA sign-in की रक्षा करता है, उसके बाद आने वाले सेशन की नहीं। अगर कोई संदेश आपसे ऐसे पृष्ठ पर कोड डालने को कहे जो आपने खुद नहीं खोला, तो रुकें और रिपोर्ट करें।
इस्तेमाल करें: Administrators और help desk कर्मचारी सेशन रद्द करना, MFA तरीकों और पंजीकृत डिवाइसों की समीक्षा, छिपे inbox rules ढूँढना और Conditional Access नीति पढ़ना कर पाएँ। आपको पता होना चाहिए कि अकेला password reset पूरा जवाब क्यों नहीं है।
महारत पाएँ: सुरक्षा आर्किटेक्ट और identity स्वामियों को token चोरी को ध्यान में रखकर डिज़ाइन करना चाहिए। इसका मतलब है authentication strengths चुनना, पहले report-only परीक्षण के साथ token protection लागू करना, तय करना कि device code flow की सचमुच किसे ज़रूरत है, और sign-in logs को ऐसी जगह भेजना जहाँ घुसपैठिया उन्हें बदल न सके।
अभी आप क्या अनदेखा कर सकते हैं
Huntress रिपोर्ट के IP addresses, user agents या client IDs आपको याद रखने की ज़रूरत नहीं। वे hunters के लिए संकेतक हैं और पुराने पड़ जाएँगे। जो टिकता है वह पैटर्न है: एक सामान्य sign-in, उसके जल्द बाद MFA बदलाव, एक नया डिवाइस, और एक छिपा mail rule।
एक व्यावहारिक अगला क़दम
अपने sign-in logs खोलें और ऐसा कोई खाता देखें जिसने अनजान जगह से sign-in के कुछ घंटों के भीतर नया MFA तरीका पंजीकृत किया हो। फिर जाँचें कि आपका tenant device code flow की अनुमति देता है या नहीं। अगर आपको उसकी कभी ज़रूरत नहीं पड़ी, तो पहले report-only मोड में ब्लॉक नीति बनाएँ और उसे चालू करने से पहले नतीजे पढ़ें।
और गहराई में
रिपोर्टें और कवरेज
- Token spray and replay in Microsoft 365, Huntress, Andrea Hatcher, Susannah Matt, Matt Poto और Andrew Schwartz, October 22, 2026, पूरी समय-रेखा, टूलिंग और संकेतक।
- The Hacker News on the Huntress findings, The Hacker News, Ravie Lakshmanan, October 26, 2026, एक छोटा सार।
Microsoft दस्तावेज़ीकरण
- Token protection in Conditional Access, Microsoft Learn, समर्थित प्लैटफ़ॉर्म और तैनाती के चरण।
- Continuous access evaluation, Microsoft Learn, घटनाएँ, अवधियाँ और सीमाएँ।
- Block device code flow, Microsoft Learn, नीति के चरण।
- Authentication strengths, Microsoft Learn, phishing-resistant समूह।
इस लेख के तथ्य 26 October 2026 को जाँचे गए थे। Microsoft की सुविधाएँ और Huntress की रिपोर्ट बदल सकती हैं, इसलिए कार्रवाई से पहले ऊपर के स्रोतों से पुष्टि करें।
यह लेख Huntress और Microsoft जो कहते हैं उसे हमारे अनुमान से अलग रखता है।
TechiesJournal पर संबंधित लेख
- Phishing Attacks, TechiesJournal, बुनियादी बातें।
- जब कोई भरोसेमंद क्लाउड एप्लिकेशन हमले का रास्ता बन जाता है, TechiesJournal, Microsoft 365 का एक अलग identity जोखिम।