آغاز حمله با فیشینگ هدفمند برای استقرار بدافزار GRIMWEDGE
به گفته پژوهشگران شرکت Volexity، مهاجمان در ایمیل‌های فیشینگ، کاربران را به کلیک روی لینکی ترغیب می‌کردند که آن‌ها را به وب‌سایت یک دانشگاه در آمریکا هدایت می‌کرد. این لینک با سوءاستفاده از آسیب‌پذیری XSS بازتابی (Reflected XSS) در وب‌سایت دانشگاه، مسیر کاربر را به سمت زیرساخت تحت کنترل مهاجمان تغییر می‌داد؛ زیرساختی که زنجیره‌ای چندمرحله‌ای از اکسپلویت‌ها را میزبانی می‌کرد.
این زنجیره اکسپلویت که پیش‌تر Proofpoint نیز به آن اشاره کرده بود، از سه آسیب‌پذیری مجزا تشکیل شده است؛ دو مورد در کروم و یک مورد در فراخوانی لوکال پیشرفته (Advanced Local Procedure Call -ALPC) در ویندوز. در مرحله نخست، مهاجمان با سوءاستفاده از CVE-2026-85046 امکان خواندن و نوشتن دلخواه در سندباکس موتور V8 را به دست می‌آورند. سپس با بهره‌گیری از CVE-2026-87491 از سندباکس مرورگر فرار می‌کنند. در مرحله نهایی نیز از CVE-2026-85880 برای تزریق کد به پردازه مرورگر کروم و اجرای کد دلخواه استفاده می‌کنند.
گروه UTA0560 از این زنجیره اکسپلویت برای استقرار بدافزار GRIMWEDGE استفاده کرده است؛ بدافزاری که قابلیت‌هایی مانند شناسایی سیستم، مدیریت فایل‌ها و پردازه‌ها، اجرای دستورات و دریافت پیلودهای بیشتر را در اختیار مهاجمان قرار می‌دهد.
زنجیره BlueMoon و استقرار پیلود چندمرحله‌ای
مهاجمان با بهره‌گیری از این آسیب‌پذیری، زنجیره اکسپلویت روز صفر موسوم به BlueMoon را فعال کردند تا بدافزار GRIMWEDGE را روی سیستم هدف مستقر کنند. همچنین، مهاجمان پیش از اجرای زنجیره اکسپلویت بررسی می‌کردند که سیستم هدف کروم را روی ویندوز اجرا می‌کند یا خیر؛ اگر این شرط برقرار نبود، زنجیره حمله روی سیستم ادامه پیدا نمی‌کرد.
در آخرین مرحله از زنجیره حمله، یک صفحه وب حاوی کد اکسپلویت بارگذاری می‌شد. این صفحه سه شِل‌کد (Shellcode) را در قالب رشته‌های کدگذاری‌شده با Base64 داخل کد جاوااسکریپت (JavaScript) خود قرار داده بود. این شِل‌کدها که با نام‌های p1، p2 و pp مشخص شده بودند، هرکدام مرحله‌ای از حمله را پیش می‌بردند:
p1: برای شناسایی و جمع‌آوری مشخصات سیستم قربانی به کار می‌رفت. این شِل‌کد با بارگذاری بازتابی (Reflective Loading) یک DLL، اطلاعات مربوط به میزبان را جمع‌آوری می‌کرد تا مهاجمان بتوانند سیستم هدف را شناسایی کنند.
p2: مرحله افزایش سطح دسترسی (Privilege Escalation) را بر عهده داشت. این شِل‌کد نیز یک DLL را به‌صورت بازتابی در حافظه بارگذاری می‌کرد و از آن برای افزایش سطح دسترسی در کرنل ویندوز (Windows Kernel) استفاده می‌شد.
pp: برای آماده‌سازی مرحله بعدی حمله به کار می‌رفت. این شِل‌کد با تزریق کد به پردازه مرورگر، امکان دریافت پیلود بعدی را فراهم می‌کرد.
در حملات منتسب به UTA0560، پیلود مرحله بعد فایل اجرایی msgbox.exe بود که به‌عنوان یک لودر (Loader) عمل می‌کرد. این فایل حاوی یک باینری معتبر ویندوز و یک DLL مخرب با نام wsc.dll بود و با استخراج آن‌ها، زمینه را برای بارگذاری جانبی DLL (DLL Sideloading) فراهم می‌کرد.
سپس wsc.dll با همان سرور تحت کنترل مهاجمان ارتباط برقرار کرده و یک فایل متنی را دریافت می‌کرد که نام آن بر اساس نام میزبان (Hostname) دستگاه شناسایی‌شده در مرحله جمع‌آوری مشخصات سیستم تعیین شده بود. این فایل در واقع یک نصب‌کننده MSI بود که یک بکدور جاوااسکریپت مبهم‌سازی‌شده (Obfuscated) را در بخش اقدامات سفارشی (Custom Actions) خود جای داده بود.
کنترل سیستم قربانی با بدافزار GRIMWEDGE
بدافزار GRIMWEDGE پس از اجرا با ایجاد یک لوپ پایدار (Persistent Command Loop) برای دریافت دستورات به‌صورت دوره‌ای با سرور فرماندهی و کنترل (C2) در آدرس ocr.opusaccel[.]top ارتباط برقرار می‌کرد. دستورات دریافتی نیز با استفاده از تابع eval() مستقیماً در حافظه اجرا می‌شدند.
این بدافزار از مجموعه‌ای از دستورات برای کنترل سیستم آلوده پشتیبانی می‌کرد:
- Info: جمع‌آوری اطلاعات و شناسایی مشخصات سیستم
- Dir: دریافت فهرست فایل‌ها و پوشه‌های یک دایرکتوری
- Mkdir: ایجاد یک دایرکتوری
- Del: حذف یک فایل
- Tasklist: فهرست‌کردن پردازه‌های در حال اجرا
- Taskkill: خاتمه‌دادن به یک پردازه با استفاده از شناسه پردازه (PID)
- Type: خواندن محتوای یک فایل با حداکثر حجم ۵ مگابایت
- Run: اجرای یک دستور در پنجره‌ای مخفی
- Upload (chunk): دریافت یک قطعه از فایل با کدگذاری Base64 از سرور C2 و افزودن آن به یک بافر درون حافظه
- Upload (commit): ذخیره بافر جمع‌آوری‌شده روی دیسک و ایجاد فایل نهایی
پژوهشگران Volexity اعلام کردند این بکدور فاقد سازوکار داخلی برای پایداری (Persistence)، حرکت جانبی (Lateral Movement) یا استخراج و انتقال داده‌ها (Exfiltration) است و قابلیت‌های مرتبط با داده عمدتاً به خواندن و بارگذاری فایل‌ها محدود می‌شود. بااین‌حال، این بکدور دسترسی اولیه کافی به سیستم آلوده را در اختیار UTA0560 قرار می‌دهد تا مهاجمان بتوانند سیستم را بررسی کنند، فایل‌های موردنظر را دریافت نمایند و از طریق دستورات Run و Upload ابزارهای بیشتری را روی سیستم مستقر کنند.
استفاده JungleBamboo از زنجیره اکسپلویت کروم و ویندوز
همچنین Volexity از شناسایی یک عامل تهدید دیگر با ارتباطات چین، موسوم به JungleBamboo و شناخته‌شده با نام APT31، خبر داده است که تقریباً در همان بازه زمانی از همین زنجیره اکسپلویت برای استقرار یک لودر با نام SUPERSTOMP استفاده کرده است. این لودر در مرحله بعد، افزونه مخرب LONGTALE را که با نام GemStone نیز شناخته می‌شود، از یک سرور راه دور دریافت کرده و روی سیستم نصب می‌کرد. برخلاف بدافزار GRIMWEDGE، هدف اصلی LONGTALE سرقت اطلاعات و اعتبارنامه‌های کاربران و نظارت بر فعالیت آن‌ها بود.
این افزونه برای فرار از شناسایی، خود را به‌عنوان افزونه رسمی گوگل جمنای (Google Gemini) معرفی می‌کرد و از شناسه ckiknalbeplpcpofpnabcnhjcegckfei استفاده می‌کرد. LONGTALE مجموعه‌ای از قابلیت‌های سرقت اطلاعات و نظارت بر فعالیت کاربران را در اختیار مهاجمان قرار می‌داد، از جمله:
- ثبت کلیدهای فشرده‌شده (Keylogging) و اطلاعات فرم‌ها
- سرقت کوکی‌ها و نشست‌های کاربری
- تهیه اسکرین‌شات
- استخراج گسترده داده‌ها
- فرماندهی و کنترل از راه دور (Remote Command and Control)
Volexity اعلام کرد LONGTALE حتی قابلیت پایه اجرای کد از راه دور (RCE) را نیز ندارد؛ قابلیتی که می‌توانست به مهاجمان اجازه دهد پس از نفوذ، اقدامات بیشتری روی سیستم‌های آلوده انجام دهند. به گفته این شرکت، ممکن است مهاجمان اساساً به قابلیت اجرای کد از راه دور نیاز نداشته باشند؛ زیرا قابلیت‌های گسترده LONGTALE در زمینه سرقت اطلاعات، برای سرقت اعتبارنامه‌ها و نظارت بر فعالیت کاربران و در نتیجه، پیشبرد اهداف JungleBamboo کافی بوده است.
ردپای یک زنجیره اکسپلویت مشترک در چند حمله
استفاده تقریباً هم‌زمان چند عامل تهدید مرتبط با چین از یک زنجیره اکسپلویت یکسان در کروم و ویندوز، این احتمال را مطرح کرده است که این زنجیره پس از مهندسی معکوس تغییرات اعمال‌شده در کد منبع کرومیوم (Chromium)، توسط توسعه‌دهنده اکسپلویت به چند گروه تهدید فروخته شده یا در اختیار آن‌ها قرار گرفته باشد.
یکی از نکات مهم در این حملات، فاصله زمانی میان انتشار پچ و انتشار نسخه پایدار (Patch Gap) است. اگرچه پچ‌های دو آسیب‌پذیری کروم در کد منبع متن‌باز کرومیوم اعمال شده بودند، اما این اصلاحات هنوز به نسخه پایدار گوگل کروم نرسیده بودند. در نتیجه، این دو آسیب‌پذیری پس از پچ‌شدن در کرومیوم در دسته N-Day قرار گرفتند، اما چون پچ آن‌ها هنوز به نسخه پایدار کروم نرسیده بود، همچنان در این مرورگر قابل سوءاستفاده بودند و عملاً به آسیب‌پذیری‌های روز صفر (Zero-Day) تبدیل شدند.
در چنین شرایطی، بدافزار GRIMWEDGE تنها یکی از پیلودهایی بود که مهاجمان توانستند با استفاده از این فاصله زمانی روی سیستم‌های هدف مستقر کنند.
کروم تا هفته گذشته نسخه‌های اصلی خود را هر چهار هفته یک‌بار منتشر می‌کرد، اما اکنون این چرخه به دو هفته کاهش یافته است. به گفته Volexity، مهاجمان ممکن است تلاش کرده باشند پیش از انتشار پچ‌های رسمی گوگل و از بین رفتن فرصت سوءاستفاده از این آسیب‌پذیری‌ها، از این فاصله زمانی استفاده کنند.
Volexity هشدار داده است که فاصله زمانی میان انتشار پچ و نسخه پایدار، فرصت بیشتری برای سوءاستفاده از آسیب‌پذیری‌ها در اختیار مهاجمان قرار می‌دهد. این موضوع با افزایش توانایی مدل‌های زبانی بزرگ (LLMs) در شناسایی سریع‌تر آسیب‌پذیری‌ها و توسعه اکسپلویت‌ها، اهمیت بیشتری پیدا کرده است.
