ScreenConnect connection ہی malware پھیلا سکتی ہے—صرف client ہٹانا کافی نہیں
7 ستمبر 2026 کو شائع ہونے والی SecurityWeek کی رپورٹ کے مطابق سماجی فریب سے نصب کیے گئے ترمیم شدہ ScreenConnect clients نئی Host connections پر چار VBScript فائلیں منتقل اور execute کر سکتے ہیں۔ یہ سرگرمی اگست کے اواخر میں مختلف اداروں کے Windows endpoints پر دیکھی گئی؛ سرکاری fix ابھی زیرِ تیاری اور عارضی mitigation دستیاب ہے۔
اس لیے خطرہ ابتدائی rogue client تک محدود نہیں رہتا: متاثرہ client سے connection یا بعد کی reconnection دوسرے endpoint پر malware chain دوبارہ چلا سکتی ہے۔ صرف client uninstall کرنا مکمل صفائی نہیں، کیونکہ مشاہدہ شدہ payload نے persistence قائم کرنے، دفاعی controls سے بچنے اور پوشیدہ ScreenConnect client چھوڑنے کی کوشش بھی کی۔
داخلہ سماجی فریب سے ہوا، خودکار exploit سے نہیں
دستیاب واقعات میں مہم نے انٹرنیٹ پر ScreenConnect servers خود تلاش کرکے exploit کرنے والے روایتی worm کی طرح آغاز نہیں کیا۔ ایک واقعے میں جعلی technical support نے صارف سے Windows Quick Assist کھلوایا؛ دوسرے میں ممکنہ phishing کے بعد Microsoft Edge کی download directory سے ScreenConnect.ClientSetup.msi چلایا گیا۔ 24 اگست کے واقعے میں Geek Squad refund form تلاش کرنے والے صارف کو rogue ScreenConnect client download اور execute کرنے پر آمادہ کیا گیا۔
اسی لیے worm-like کی حد واضح رکھنا ضروری ہے۔ انسانی فریب ابتدائی foothold بناتا ہے، لیکن ترمیم شدہ client نصب ہونے کے بعد نئی ScreenConnect Host sessions پر scripts کی ترسیل خودکار ہو سکتی ہے۔ Incident timeline میں غیر متوقع support درخواست، Quick Assist session، browser سے چلایا گیا MSI اور بعد کی ScreenConnect activity کو باہم جوڑنا چاہیے۔
نئی Host connection چار scripts چلا سکتی ہے
Huntress کی تکنیکی تحقیق میں مختلف اداروں کے rogue clients سے ScreenConnect.WindowsClient.exe کے بار بار wscript.exe child processes بنانے اور 1.vbs، 2.vbs، 3.vbs اور 4.vbs چلانے کا مشترک pattern درج ہے۔ یہ scripts نظام کا جائزہ لیتیں، اگلا payload حاصل اور decrypt کرتیں، PowerShell چلاتیں اور staging کی بعض فائلیں حذف کر دیتیں۔
تحلیل شدہ access variant نے UAC اور AMSI bypass کی کوشش کی، Microsoft Defender میں exclusion شامل کیا اور ایک ScreenConnect client نصب کرکے اس کی service اور uninstall entry چھپانے کی کوشش کی۔ ترمیم شدہ client نئی Host sessions کے ConnectionID دیکھتا، محفوظ شدہ چار scripts کو ScreenConnect کے virtual file-transfer mechanism میں درج کرتا اور انہیں منسلک Host پر چلانے کے لیے queue کر دیتا تھا۔
client ہر active ConnectionID محفوظ کرکے اسی session کو بار بار نشانہ بنانے سے گریز کرتا تھا، مگر disconnect ہونے پر وہ شناخت ہٹا دیتا تھا۔ نتیجتاً بعد کی reconnection اسی endpoint پر چار مرحلوں والی chain دوبارہ متحرک کر سکتی تھی۔ یہی مشاہدہ عنوان کے مرکزی نتیجے کی تائید کرتا ہے: مشتبہ client کو صرف disconnect کرکے دوبارہ جوڑنا محفوظ validation طریقہ نہیں۔
RunFiles اور RanFiles پھیلاؤ کا دائرہ دکھا سکتے ہیں
ScreenConnect server audit logs میں RunFiles یا RanFiles entries فوری forensic اشارے ہیں، بالخصوص جب 1.vbs سے 4.vbs تک scripts، Windows Script Host یا PowerShell کا اجرا Process: Guest سے منسوب ہو۔ معلوم filenames بدل سکتے ہیں، اس لیے تلاش کو انہی چار ناموں تک محدود کرنے کے بجائے Guest context سے غیر متوقع script execution، file transfer اور متعلقہ session timing بھی دیکھی جائے۔
Server timeline کو endpoint telemetry کے ساتھ ملانے سے rogue client کی تنصیب، پہلی Host connection اور scripts کے اجرا کی ترتیب بن سکتی ہے۔ متعلقہ شواہد میں ScreenConnect process سے نکلنے والا wscript.exe، browser download سے چلا MSI، Temp directory کی scripts، AppData میں WindowsServiceHost.vbs اور HKCU Run path کی WindowsServiceHost entry شامل ہیں۔ بعض متاثرہ hosts پر UltraViewer بھی ملا، اس لیے اضافی remote-access tools کو scope سے باہر نہیں سمجھنا چاہیے۔
تحقیقات کا دائرہ صرف پہلے متاثرہ کمپیوٹر تک محدود نہ رکھا جائے۔ مشتبہ client سے جڑی تمام Host sessions، ان کے ConnectionIDs، connection times اور file-transfer actions محفوظ کرنا ضروری ہے، کیونکہ بظاہر صاف endpoint بھی payload وصول کر چکا ہو سکتا ہے۔ MSP ماحول میں یہی session history مختلف managed customers تک ممکنہ پھیلاؤ کی حد متعین کرنے کی بنیاد بنے گی۔
Fix سے پہلے containment کی ترتیب
ConnectWise کی 3 ستمبر کی عبوری ہدایت Remote Access Support اور Access sessions کے file-transfer behavior کو مسئلے کے دائرے میں رکھتی ہے؛ cloud اور on-premises دونوں deployments متاثر ہیں، status “fix in development” ہے اور عارضی mitigation فوراً نافذ کی جا سکتی ہے۔ کمپنی نے official fix تک ہر assigned role اور اس کے ہر scoped session group میں TransferFiles، یا legacy versions میں TransferFilesInSession، permission غیر منتخب کرنے کی ہدایت دی ہے؛ اس تبدیلی کے لیے version upgrade درکار نہیں۔
عملی incident response میں evidence مٹائے بغیر پھیلاؤ روکنا پہلی ترجیح ہے۔ اس کے بعد audit logs اور endpoint artifacts محفوظ کرکے پورے managed estate میں متعلقہ indicators تلاش کیے جائیں، پھر permissions محدود کی جائیں اور متاثرہ hosts کی recovery الگ مرحلے میں کی جائے۔
- Sessions محدود کریں: مشتبہ client سے نئی اور دوبارہ قائم ہونے والی connections روکیں، مگر server اور endpoint evidence محفوظ رہنے دیں۔
- دائرہ متعین کریں: RunFiles، RanFiles، Process: Guest، file transfers اور ConnectionIDs کی مشترک timeline بنائیں۔
- ہر role جانچیں: تمام bold یا assigned session groups میں TransferFiles permission الگ الگ دیکھیں؛ صرف ایک default role بدلنا کافی نہیں۔
- Persistence تلاش کریں: User Run Key، AppData scripts، پوشیدہ ScreenConnect service، PowerShell activity اور اضافی RMM software کا جائزہ لیں۔
- قابلِ اعتماد recovery کریں: متاثرہ hosts کو known-good media سے reimage یا صاف operating-system installation کے ذریعے بحال کرنے کو ترجیح دیں، کیونکہ client uninstall باقی payload اور persistence ختم ہونے کا ثبوت نہیں۔
File transfer بند کرنے سے جائز remote-support workflow متاثر ہو سکتا ہے، مگر patch سے پہلے یہ پھیلاؤ کا راستہ محدود کرتا ہے۔ یہ مکمل remediation نہیں: اگر payload پہلے چل چکا ہو تو permission change موجود persistence، دوسرے remote-access tools یا endpoint پر کی گئی دفاعی تبدیلیاں واپس نہیں کرتا۔
Fix اور CVE ابھی باقی ہیں
8 ستمبر 2026 تک دستیاب advisory میں patched release زیرِ تیاری ہے، جبکہ CVE identifier اور تازہ deployment guidance بھی بعد میں جاری ہونا ہیں۔ عوامی معلومات متاثرہ اداروں کی مجموعی تعداد، تمام campaign operators یا ہر payload branch کے حقیقی استعمال کا مکمل حساب نہیں دیتیں؛ مشاہدات مختلف اداروں کے متعدد incidents دکھاتے ہیں، پوری ScreenConnect آبادی میں خودکار infection ثابت نہیں کرتے۔
فی الحال ثابت شدہ نتیجہ محدود مگر سنجیدہ ہے: social engineering سے نصب rogue ScreenConnect client نئی Host connection کو malware delivery میں بدل سکتا ہے، اور reconnection خطرہ دوبارہ پیدا کر سکتی ہے۔ اسی لیے server-side audit evidence، عارضی permission containment اور compromised host کی known-good recovery تین الگ ضروری کام ہیں؛ صرف client ہٹا دینا ان سب کا متبادل نہیں۔
یہ بھی پڑھیں:
ہمارا نیوز لیٹر سبسکرائب کریں
ویب 3، AI اور کرپٹو کی تازہ خبریں براہ راست اپنے اِن باکس میں پائیں۔