Teams پر جعلی IT مدد نے پورا نیٹ ورک کھولا—external label کافی نہ رہا
Microsoft Threat Intelligence نے 2 ستمبر 2026 کو انسانی مداخلت سے چلنے والی ایک مہم کی تفصیل شائع کی: حملہ آور بیرونی Microsoft Teams tenant سے IT یا helpdesk اہلکار بنے، صارفین سے remote control لیا اور پھر ایک endpoint کو پورے ادارے میں پیش قدمی کے راستے میں بدل دیا۔ Microsoft کی تحقیق میں malicious MSI، portable Node.js runtime، JavaScript implant، Active Directory کی کھوج اور WinRM کے ذریعے domain controllers اور certificate authorities سمیت اہم نظاموں کی جانب روابط درج ہیں۔
یہ Microsoft Teams کی ایسی کمزوری نہیں جس سے صرف پیغام کھولنے پر آلہ متاثر ہو جائے؛ فیصلہ کن قدم صارف سے Teams screen sharing کا “request control” منظور کرانا، Quick Assist code لینا یا کسی جائز remote-support tool کا session شروع کرانا تھا۔ TechRadar کی 3 ستمبر کی رپورٹ نے بیرونی Teams رابطے، remote access، malware، reconnaissance اور lateral movement کا یہی سلسلہ بیان کیا، البتہ اس کا ransomware اور data theft کو انجام کہنا Microsoft کے شائع کردہ شواہد سے زیادہ قطعی ہے: بنیادی تحقیق انہیں ممکنہ اگلے نتائج قرار دیتی ہے، اس مہم کا ثابت شدہ انجام نہیں۔
ایک Teams رابطہ ادارے کے اندرونی نظاموں تک کیسے پہنچا
حملے کی طاقت کسی ایک غیر معمولی binary میں نہیں بلکہ اعتماد اور جائز tools کی مسلسل زنجیر میں تھی۔ بیرونی شخص “security update”، “spam filter update”، account verification یا account بند ہونے کا بہانہ بناتا، کبھی voice call بھی شامل کرتا، اور صارف کو security warning نظر آنے کے باوجود remote session منظور کرنے پر آمادہ کرتا تھا۔
کنٹرول ملنے کے بعد operator نے PowerShell سے cloud storage پر موجود update جیسے نام والا MSI اتارا اور msiexec کے ذریعے خاموشی سے نصب کیا۔ پیکیج نے LocalAppData میں script loader اور encrypted JavaScript implant رکھا؛ Node.js دستیاب نہ ہونے پر جائز portable runtime حاصل کرکے اسی user-writable directory سے implant چلایا گیا۔ PowerShell، Windows Installer، WScript اور Node.js الگ الگ معمول کی چیزیں ہو سکتی ہیں، مگر یہاں ان کی ترتیب نقصان دہ تھی۔
Implant نے HTTPS کے ذریعے ہدایات لیں، host، security products اور virtual environment کی معلومات جمع کیں اور desktop کے وقفے وقفے سے captures بنائے۔ اس کے بعد ADSI اور مقامی Windows tools سے domain accounts، users اور servers تلاش کیے گئے، جبکہ مزید DLL payloads rundll32 سے چلائے جا سکتے تھے۔
آخر میں Node.js backdoor سے TCP port 5985 پر WinRM connections domain-joined systems کی ایک بڑی تعداد کی طرف گئے، جن میں domain controllers اور certificate authorities بھی شامل تھے۔ عنوان میں “پورا نیٹ ورک کھولا” اسی credential-backed، enterprise-wide راستے کو بیان کرتا ہے؛ دستیاب شواہد ہر ہدف کے مکمل compromise یا ہر متاثرہ ادارے میں ransomware ثابت نہیں کرتے۔
ملازم کے لیے 60 سیکنڈ کا support-verification طریقہ
External label خطرے کا اشارہ ہے، شناخت کی ضمانت نہیں۔ غیر متوقع support رابطے میں control، code، command، download یا MFA approval دینے سے پہلے گفتگو روکنا اصل حفاظتی لمحہ ہے۔ پاکستانی کاروبار، جامعہ یا سرکاری ادارہ اس وقفے کو مختصر اور قابلِ عمل بنانے کے لیے پہلے سے معروف داخلی راستہ مقرر کر سکتا ہے:
- Teams chat یا call روکیں؛ screen control منظور نہ کریں اور Quick Assist code نہ بتائیں۔
- خود helpdesk portal کھولیں یا ادارے کی directory میں محفوظ extension پر رابطہ کریں؛ caller کا دیا ہوا link یا نمبر استعمال نہ کریں۔
- ticket number، درخواست کرنے والا شعبہ اور technician کی شناخت اسی الگ داخلی channel سے ملائیں۔
- ticket نہ ملے، external tenant غیر متوقع ہو یا شخص فوری control پر اصرار کرے تو chat report کرکے IT یا SOC کو account، tenant اور رابطے کا وقت دیں۔
“60 سیکنڈ” کوئی تجرباتی ضمانت نہیں بلکہ ایک مختصر operational stop ہے جسے ادارہ اپنے helpdesk workflow میں نافذ کر سکتا ہے۔ جائز technician کے لیے آزاد callback، ticket verification اور منظور شدہ support tool قابلِ قبول ہونے چاہییں؛ اسی گفتگو کے اندر عجلت پیدا کرنا خود ایک اہم خطرے کی علامت ہے۔
SOC کو الگ alerts کے بجائے پوری ترتیب دیکھنی ہوگی
SOC کے لیے مضبوط signal بیرونی Teams persona سے شروع ہونے والی ایک timeline ہے: chat یا call، پھر screen sharing، Quick Assist یا RMM session، اور فوراً بعد اسی user context میں cmd.exe یا PowerShell۔ اس کے ساتھ cloud-hosted MSI کا download اور msiexec کی silent execution ملے تو واقعے کی ترجیح بڑھ جانی چاہیے۔
اگلی کڑیاں LocalAppData جیسی user-writable path سے node.exe یا اس کی renamed copy، WScript سے loader کا اجرا، اور Run key یا Startup shortcut میں update جیسے نام سے persistence ہیں۔ انہی واقعات کے بعد screen capture، antivirus یا virtualization discovery، ADSI/LDAP queries، domain enumeration اور rundll32 سے نامعلوم DLL چلنے کو ایک ہی incident میں جوڑنا چاہیے۔
نیٹ ورک پر اہم علامت عام workstation یا غیر انتظامی process سے TCP 5985 پر متعدد اندرونی systems کو WinRM traffic ہے، خصوصاً domain controllers اور certificate authorities کی طرف۔ PowerShell، Node.js اور WinRM جائز انتظامی استعمال رکھتے ہیں، اس لیے کسی ایک event پر فیصلہ کرنے کے بجائے user، device، parent process، file path، وقت اور destination کو external Teams رابطے کے ساتھ correlate کرنا ضروری ہے۔
وہ انتظامی controls جو external label سے آگے جاتے ہیں
Teams external access کو حقیقی کاروباری ضرورت کے مطابق trusted domains تک محدود کیا جا سکتا ہے، جبکہ غیر ضروری federation بند اور external sender notifications نمایاں رکھی جا سکتی ہیں۔ یہ پابندی خود مکمل حل نہیں: remote-support policy میں منظور شدہ tool، لازمی ticket، technician کا managed account اور control سے پہلے independent callback یا identity check واضح ہونا چاہیے۔
Endpoint پر RMM اور interactive support tools کی اجازت محدود اور monitored ہو۔ PowerShell، WScript، downloaded MSI اور user-writable directories سے script execution کے لیے مناسب attack-surface reduction اور detection policies، phishing-resistant MFA، managed-device requirements اور Conditional Access چوری شدہ یا دستیاب credentials کی افادیت گھٹا سکتے ہیں۔
WinRM کو عام user endpoints سے پورے domain کے لیے دستیاب رکھنے کے بجائے منظور شدہ administrative workstations اور مخصوص management accounts تک محدود کرنا مرکزی رکاوٹ ہے۔ Domain controllers اور certificate authorities پر source-based restrictions اور user-context WinRM alerts اس pivot کو روک سکتے ہیں جسے external label دیکھ ہی نہیں سکتا، کیونکہ وہ صرف پہلی گفتگو کی نوعیت بتاتا ہے، منظور شدہ remote session کے اندر ہونے والی سرگرمی نہیں۔
Remote session ہو چکا ہو تو دائرہ صرف پہلے laptop تک محدود نہ رکھیں
Session ختم کرنا یا MSI حذف کرنا مکمل remediation کا ثبوت نہیں؛ operator credentials استعمال، اضافی persistence یا دوسرے hosts تک رسائی حاصل کر چکا ہو سکتا ہے۔ Endpoint کو isolate کرتے ہوئے صفائی سے پہلے Teams conversation، external tenant، remote-support artifacts، Entra sign-ins، PowerShell logs، MSI installation، registry، process tree اور network telemetry محفوظ ہونی چاہیے۔
متاثرہ device پر دستیاب passwords، tokens، browser sessions اور secrets کا دائرہ طے کرکے متعلقہ sessions revoke اور credentials rotate کیے جائیں۔ WinRM connections اور authentication records سے ہر destination host الگ جانچا جائے؛ privileged account استعمال ہوا ہو یا domain controller یا certificate authority کی طرف رسائی نظر آئے تو identity infrastructure کی investigation کو ابتدائی endpoint کی صفائی پر ختم نہیں کرنا چاہیے۔
Awarely Monitor کی 3 ستمبر کی تکنیکی جانچ کے مطابق متاثرہ اداروں یا ممالک کی تعداد، victims کے نام اور ذمہ دار actor کی attribution عوامی طور پر جاری نہیں ہوئی۔ اس وقت تصدیق شدہ خبر observed attack chain، اہم defensive signals اور enterprise-wide access کی صلاحیت ہے؛ data theft، extortion یا ransomware کو اس مخصوص مہم کا مکمل شدہ نتیجہ کہنا دستیاب شواہد سے ثابت نہیں۔
یہ بھی پڑھیں:
ہمارا نیوز لیٹر سبسکرائب کریں
ویب 3، AI اور کرپٹو کی تازہ خبریں براہ راست اپنے اِن باکس میں پائیں۔