EvilTokens کا account ملا؟ password بدلنے سے پہلے tokens بھی منسوخ کریں

EvilTokens سے جڑے device-code phishing کے بعد Microsoft 365 اکاؤنٹ متاثر ہونے کا شبہ ہو تو پہلے اس کا sign-in عارضی طور پر بند کریں، پھر refresh tokens منسوخ کریں؛ صرف password بدل کر اکاؤنٹ نہ کھولیں۔ Microsoft کی EvilTokens تحقیق یہی containment ترتیب تجویز کرتی ہے اور خبردار کرتی ہے کہ session revocation کے بعد پہلے سے جاری access tokens بعض صورتوں میں ایک گھنٹے تک کارآمد رہ سکتے ہیں۔

اس حملے میں صارف حقیقی Microsoft صفحے پر device code داخل کر سکتا ہے، مگر code شروع کرنے والا session حملہ آور کا ہوتا ہے؛ اسے password جاننے کی ضرورت نہیں رہتی۔ Cloudflare کی تحقیق کے مطابق EvilTokens کا نظام authentication tokens جمع کرنے اور session token کی میعاد ختم ہونے کے بعد بھی رسائی برقرار رکھنے کے لیے بنایا گیا تھا۔ اس لیے بحالی میں token revocation کے ساتھ devices، اجازت یافتہ apps، mailbox اور Microsoft Graph کی سرگرمی کا جائزہ بھی شامل ہے۔

ابتدائی ثبوت لیں، مگر containment میں تاخیر نہ کریں

سب سے پہلے متاثرہ صارف کا UPN، مشتبہ sign-in کا وقت، متعلقہ alert اور phishing پیغام یا URL محفوظ کریں۔ یہ ابتدائی، read-only جانچ ہے: ابھی rules یا devices حذف نہ کریں۔ اگر حملہ جاری دکھائی دے تو مکمل تفتیش کا انتظار کیے بغیر اکاؤنٹ بند کریں؛ بعد میں ملنے والے شواہد کو اسی ابتدائی وقت کے ساتھ جوڑا جا سکتا ہے۔

Entra کے interactive اور non-interactive sign-in logs میں صارف، وقت، IP address، مقام، application، authentication flow، device کی شناخت اور Conditional Access کا نتیجہ دیکھیں۔ Defender میں دستیاب device-code یا token-exchange alerts اور Entra audit logs میں device registration کے واقعات بھی اسی ٹائم لائن میں رکھیں۔ اصل log entries برآمد کریں اور اپنی ہر انتظامی کارروائی کا وقت درج کریں، تاکہ بعد کی تبدیلی کو حملہ آور کی کارروائی نہ سمجھ لیا جائے۔ اگر صرف alert ملا ہے اور کامیاب مشتبہ sign-in نہیں ملا تو اسے تصدیق شدہ اکاؤنٹ قبضہ قرار دینے کے بجائے مزید جانچ کا اشارہ سمجھیں۔

اکاؤنٹ بند کریں اور refresh tokens منسوخ کریں

متاثرہ صارف کے لیے sign-in بند کریں اور Entra میں تصدیق کریں کہ account enabled نہیں رہا۔ Microsoft کی compromised-account ہدایات تفتیش مکمل ہونے تک اکاؤنٹ بند رکھنے، sign-in sessions منسوخ کرنے اور بحالی سے پہلے برقرار رہنے والی رسائی کے دوسرے راستے دیکھنے کو کہتی ہیں۔ بندش کی انتظامی کارروائی اور اس کا وقت محفوظ کریں؛ اگر بندش ممکن نہ ہو تو password فوراً بدلیں اور باقی containment اقدامات جاری رکھیں۔

پھر مناسب انتظامی اختیار کے ساتھ Microsoft Graph PowerShell میں Connect-MgGraph -Scopes User.RevokeSessions.All چلائیں اور متاثرہ صارف کے لیے Revoke-MgUserSignInSession -UserId <UPN> استعمال کریں۔ <UPN> کو اسی اکاؤنٹ کی اصل شناخت سے بدلیں اور command کا نتیجہ، ہدف اور وقت محفوظ کریں۔ یہ کارروائی refresh tokens کو غیر مؤثر کرتی ہے، لیکن command کی کامیابی پہلے سے جاری ہر access token کے اسی لمحے ختم ہونے کا ثبوت نہیں؛ اسی لیے اکاؤنٹ فی الحال بند رکھیں۔

Password اس کے بعد محفوظ انتظامی راستے سے reset کریں، نیا password متاثرہ mailbox میں نہ بھیجیں۔ اگر شناخت مقامی Active Directory سے sync ہوتی ہے یا federated ہے تو اصل شناختی نظام میں بھی مطلوبہ تبدیلی کریں۔ Password reset، token revocation اور account disable الگ کارروائیاں ہیں؛ ایک کا audit record دوسری کارروائی کی تکمیل ثابت نہیں کرتا۔

Devices، MFA اور app consent میں باقی رسائی تلاش کریں

Entra audit logs میں مشتبہ sign-in کے آس پاس device join یا registration دیکھیں اور device ID، وقت اور مالک کو اپنے asset record اور صارف سے ملائیں۔ EvilTokens سے جڑی سرگرمی میں نیا device رسائی برقرار رکھنے کا ذریعہ بن سکتا ہے، مگر ہر نیا اندراج خود بخود غیر مجاز نہیں ہوتا۔ جس device کی غیر مجاز حیثیت ثابت ہو، اسے disable کریں اور audit entry محفوظ کریں؛ اگر Primary Refresh Token سے رسائی کا شبہ ہو تو صارف کے refresh tokens کی منسوخی بھی برقرار رکھیں۔

اسی اکاؤنٹ کے MFA طریقے اور registered authentication devices کی فہرست نکالیں۔ نامانوس طریقے کو ہٹانے سے پہلے اس کے شامل ہونے کا وقت اور دستیاب audit evidence محفوظ کریں، پھر جائز طریقوں کی تصدیق صارف سے ایسے رابطے پر کریں جو متاثرہ mailbox پر منحصر نہ ہو۔ user-consented applications اور اکاؤنٹ کو دیے گئے انتظامی roles بھی دیکھیں؛ غیر مجاز اجازت یا role ہٹانے کے بعد نئی فہرست سے تصدیق کریں کہ رسائی ختم ہوئی ہے۔ پرانی، جائز app اجازت کو صرف اس لیے اسی واقعے کا حصہ نہ بنائیں کہ وہ متاثرہ اکاؤنٹ میں موجود ہے۔

Mailbox اور Graph سرگرمی سے اثر کا دائرہ طے کریں

Exchange Online میں mailbox forwarding اور تمام Inbox rules، بشمول hidden rules، دیکھیں۔ خاص طور پر ایسے قواعد شناخت کریں جو پیغامات آگے بھیجتے، redirect کرتے یا نظر سے اوجھل کرتے ہیں؛ قاعدہ حذف کرنے سے پہلے اس کی ترتیب اور audit entry محفوظ کریں۔ تبدیلی کے بعد forwarding اور rules دوبارہ نکالیں تاکہ ثابت ہو کہ شناخت شدہ راستہ بند ہو چکا ہے۔

مشتبہ دورانیے کے Sent Items اور message trace کو ملائیں: کیا اکاؤنٹ سے اندرونی یا بیرونی وصول کنندگان کو پیغامات گئے، اور کیا ان کی ترسیل mailbox کے ریکارڈ سے مطابقت رکھتی ہے؟ دستیاب Defender اور workload logs میں device-code sign-in کے بعد Microsoft Graph درخواستوں، mailbox تک رسائی اور نئی inbox-rule سرگرمی کو اسی ٹائم لائن پر رکھیں۔ Graph کی غیر معمولی درخواست ایک اہم اشارہ ہے، مگر درخواست کی نوعیت اور دستیاب audit coverage دیکھے بغیر اسے ڈیٹا اخراج کا قطعی ثبوت نہ کہیں۔

اگر غیر مجاز rule، forwarding یا consent ملا ہے تو صرف اسے حذف کرنا واقعے کا اثر ختم نہیں کرتا؛ پہلے سے بھیجے گئے پیغامات اور ممکنہ طور پر دیکھی گئی mail کا دائرہ بھی طے کریں۔ اگر logs میں مزید سرگرمی نہ ملے تو یہ صرف دستیاب ریکارڈ کا نتیجہ ہے۔ اپنے incident record میں واضح لکھیں کہ کون سے logs موجود تھے، کس دورانیے کو ڈھانپا گیا اور کہاں شواہد ناکافی ہیں۔

Conditional Access کے بعد اکاؤنٹ بحال کریں

جہاں کاروباری ضرورت نہ ہو، Conditional Access میں device code flow بند کریں؛ جہاں جائز Teams یا دوسرے مخصوص devices اس پر منحصر ہوں، استثنا صرف متعلقہ اکاؤنٹس اور وسائل تک محدود رکھیں۔ متاثرہ صارف کے لیے دوبارہ authentication کی شرط بھی نافذ کریں۔ policy لگنے کے بعد sign-in logs میں اس کا نتیجہ دیکھیں: غیر مطلوب device-code کوشش block ہوئی ہو اور جائز استعمال کا راستہ حسبِ ضرورت کام کر رہا ہو۔

بحالی سے پہلے تصدیق کریں کہ غیر مجاز devices، MFA طریقے، app consent، mailbox forwarding اور rules ہٹ چکے ہیں، token revocation مکمل ہوئی ہے اور password اصل شناختی نظام میں بدل چکا ہے۔ پھر اکاؤنٹ دوبارہ فعال کریں اور صارف سے تازہ sign-in کرائیں۔ اس جائز sign-in کے Entra اور Conditional Access نتائج دیکھیں، جبکہ بعد کے Exchange اور Graph logs میں پہلے شناخت شدہ مشتبہ سرگرمی کی واپسی تلاش کریں۔ آخری ریکارڈ میں بندش، token revocation، صفائی اور بحالی کے اوقات درج کریں؛ یہی بتاتا ہے کہ محض password reset سے آگے کون سے راستے واقعی بند کیے گئے۔

یہ بھی پڑھیں:

• My Activity صاف کرنے کے بعد بھی Chrome history کیوں باقی رہتی ہے؟
• AWS Security Hub remediation خودکار کریں، پہلے sandbox میں کیوں آزمانا ہے
• Claude کا چوتھا حقیقی intrusion ملا، پہلی transcript چھان بین اسے نہ پکڑ سکی