یک بهروزرسانی مرورگر جعلی که از طریق وایفای هتلی ربوده شده بود، برای نصب CornFlake — تروجان دسترسی از راه دور — استفاده شد.
خلاصهٔ اتفاق
مایکروسافت و شرکتهای پژوهشی امنیتی حملهای را با عنوان CaptiveCrunch شناسایی کردند. مهاجمان با کنترل درگاههای captive portal در شبکههای هتلداری، ترافیک را هدایت مجدد میکردند و کاربران را به صفحات دانلود بهروزرسانی جعلی میفرستادند. این عملیات به زیرخوشهای نسبت داده شده که مایکروسافت آن را Storm-2945 میخواند و آن را مرتبط با بازیگری شناختهشدهٔ APT29 / Cozy Bear دانسته است.
بردار و روش حمله
در نمونههای بررسیشده، درگاه پورتال بهعنوان رزولور DNS دستگاههای متصل عمل کرده و مهاجمان پاسخهای DNS را جعل کردند. نتیجه آن هدایت بررسیهای اتصال سیستم به فایل نصب یا صفحهٔ بهروزرسانی جعلی بود. بخشی از صفحات فرود از دستورالعملهای «ClickFix» استفاده میکردند که کاربر را به اجرای دستورات در ترمینال یا ابزارهای ویندوز وادار میساخت؛ بهعبارت دیگر، کنترل درگاه به مهاجم امکان پخش محتوای فریبکارانه میداد اما آلودهسازی نهایی مستلزم تعامل کاربر — دانلود یا اجرای فایل مخرب — بود.
ابزارها و قابلیتهای مخرب
CornFlake
CornFlake که با زبان Go توسعه یافته، خود را در مسیر %APPDATA%\svchost32\svchost32.exe کپی و سرویس «svchost32» را با نام نمایشی Cloud Sync Service ثبت میکند. حین اجرای بدافزار یک پنجرهٔ پیشرفت جعلی کاربر را مشغول نگه میدارد، در حالی که عملیات ماندگاری و جمعآوری اطلاعات در پسزمینه انجام میشود.
قابلیتهای ثبتشده شامل موارد زیر است:
- گرفتن اسکرینشات در حالت بیکاری
- ثبت محتویات کلیپبورد همراه با عنوان پنجرهٔ فعال
- سرقت کوکیها و رمزهای ذخیرهشدهٔ مرورگر، از جمله کوکیهای محافظتشده توسط Chrome App-Bound Encryption
- اسکن رسانههای قابلحذف برای یافتن فایلهای هدف
- باز کردن شل از راه دور و اجرأی فرمان
- مکانیزمهای ماندگاری: کلید Run در رجیستری، کار زمانبندیشده و یک نگهبان که مکانیسمهای حذفشده را بازیابی میکند
ChocoShell و سرقت توکنها
نمونهٔ دیگری با نام ChocoShell شناسایی شد؛ یک استیلر اجراشونده در حافظه که با اسکریپت PowerShell توکنهای Microsoft 365، Azure AD و توکنهای Web Account Manager را از فایلهای .tbres در کش Token Broker استخراج میکند. این توکنها به مهاجم امکان بازپخش جلسه (session replay) بدون نیاز به کوکی مرورگر را میدهند.
پیامدها و گسترهٔ حمله
گزارشها نشان میدهد دستکاری ترافیک از اوایل ماه مه در شبکههای هتلداری چند کشور مشاهده شده است، اما مایکروسافت و ReliaQuest نام هیچ هتلی یا ارائهدهندهٔ پورتال را اعلام نکردهاند. وجود تجهیزات و سامانههای مدیریتی مشترک در شبکههای آسیبدیده میتواند نشاندهندهٔ نفوذ به سرویسهای مشترک در اکوسیستم پورتالهای اجباری باشد و این نفوذها ممکن است فراتر از یک محل محدود باشند.
همچنین گزارشها وسعت حملات یا نرخ موفقیت را بهصورت کمّی اعلام نکردهاند؛ به همین دلیل تعداد دستگاهها یا حسابهای سرقتشده در اسناد عمومی مشخص نیست.
توصیههای فوری برای مسافران و سازمانها
- استفاده از VPN با تونل کامل؛ این اقدام باعث میشود پرسوجوهای DNS ابتدا به رزولورهای سازمانی فرستاده شوند و درگاه محلی نتواند پاسخهای جعلی ارائه دهد. ReliaQuest همین راهکار را توصیه کرده است.
- بهروزرسانیها، گواهیها، ابزارهای عیبیابی یا امنیتی ارائهشده از طریق پورتالهای اجباری را رد کنید و هیچ فایل دانلودشده از این صفحات را اجرا نکنید.
- اگر سازمان از جریان احراز هویت «کد دستگاه» استفاده نمیکند، آن را از طریق سیاستهای Conditional Access مسدود کنید؛ مایکروسافت گزارش کرده که برخی صفحات CaptiveCrunch کاربران را به جریان کد دستگاه هدایت کردهاند تا ورود چندعاملی را دور بزنند.
- در صورت امکان از اینترنت همراه شخصی (hotspot) استفاده کنید و از شبکههای عمومی فقط در مواقع ضرورت بهره ببرید.
- برای تیمهای امنیتی: نظارت بر لاگها، بررسی توکنها و بازنگری اعتبارنامههای مدیریتی در تجهیزات مدیریت پورتالها ضروری است. مراکز پاسخ به حادثه باید زیرساختهای مشترک و دسترسیهای مدیریتی را مورد بازبینی قرار دهند.
- برای مطالعهٔ جزئیات بیشتر به منابع ReliaQuest و NCSC و وبلاگ امنیتی مایکروسافت مراجعه کنید.
نتیجهگیری و سوالهای باز
مایکروسافت این حمله را به Storm-2945 نسبت داده و برخی شباهتهای فنی به رخنههای مرتبط با گروههای دیگر مشاهده شده است، اما برخی از نسبتدهیها نیاز به تأیید فنی مستقل دارند. بردار اولیهٔ نفوذ هنوز در دست بررسی است و ReliaQuest احتمال میدهد ترکیبی از رابطهای مدیریتی در معرض و اعتبارنامههای ضعیف یا بازاستفادهشده نقش داشته باشند.
این وقایع بار دیگر یادآور میشوند که پورتالهای اجباری در شبکههای عمومی، بهویژه در هتلها، هدف جذابی برای مهاجمان هستند؛ بنابراین هر دو طرف — کاربران و ارائهدهندگان خدمات — باید تدابیر پیشگیری و واکنش را تقویت کنند.
منابع: گزارشهای مایکروسافت و ReliaQuest؛ اطلاعات تکمیلی در وبلاگ امنیتی مایکروسافت و پایگاههای تحقیقاتی امنیت سایبری.





