روابط عمومی شرکت ایدکو (توزیع‌کننده‌ی محصولات کسپرسکی در ایران)؛ Lazarus APT و زیرگروه آن، BlueNoroff عاملین تهدید کره‌ای زبانِ بسیار پیچیده و چندوجهی‌ هستند. ما فعالیت‌های آن‌ها را با دقت تحت نظر داریم و اغلب می‌بینیم که دارند در حملات خود از بدافزار امضای خود که بک‌دری تمام‌عیار به نام Manuscrypt است استفاده می‌کنند. طبق تحقیقات ما، لازاروس دست کم از سال 2013 به بدافزار را به خدمت گرفته و ما کارکردش را در بالای 50 کمپین منحصر به فرد ثبت کردیم. این کمپین‌ها به دولت‌ها، نهادهای دیپلماتیک، مؤسسات مالی، پیمانکاران نظامی و دفاعی، پلت‌فرم‌های ارزهای دیجیتال، اپراتورهای فناوری اطلاعات و مخابرات، شرکت‌های گیمینگ، رسانه‌ها، کازینوها، دانشگاه‌ها و حتی محققین امنیتی - این فهرست ادامه دارد- حمله کردند.

13 می سال 2024، محصول رده مصرف‌کننده ما Kaspersky Total Security یک عفونت جدید Manuscrypt را در رایانه شخصی فردی که در روسیه زندگی می‌کرد شناسایی کرد. از آنجایی که لازاروس به ندرت به افراد حمله می‌کند، این علاقه ما را برانگیخت و تصمیم گرفتیم نگاه دقیق‌تری روی پرونده داشته باشیم. متوجه شدیم که قبل از شناسایی Manuscrypt، فناوری‌های ما سوءاستفاده از مرورگر وب گوگل کروم را که از وب‌سایت detankzone[.]com سرچشمه می‌گیرد، شناسایی کرده‌اند. در ظاهر، این وب‌سایت شبیه یک صفحه محصول به طور حرفه‌ای طراحی‌شده  برای بازی نبرد آنلاین چندنفره تانک (موبا) بر پایه NFT بود اما این فقط یک پوشش بود. این وبسایت دارای یک اسکریپت مخفی بود که در مرورگر گوگل کروم کاربر اجرا می شد و یک اکسپلویت روز صفر را راه اندازی می‌کرد و به مهاجمین کنترل کامل بر رایانه شخصی قربانی را می‌داد. بازدید از وبسایت تنها چیزی بود که برای آلوده شدن لازم بود - بازی فقط یک حواس پرتی بود.

ما توانستیم مرحله اول حمله را استخراج کنیم - یک اکسپلویت که اجرای کد از راه دور را در فرآیند گوگل کروم انجام می‌دهد. پس از تأیید اینکه این اکسپلویت مبتنی بر یک آسیب‌پذیری روز صفر است که آخرین نسخه Google Chrome را هدف قرار می‌دهد، یافته‌های خود را در همان روز به گوگل گزارش دادیم. دو روز بعد، گوگل یک به‌روزرسانی منتشر و از ما برای کشف این حمله تشکر کرد. پس از اطلاع به گوگل در مورد آسیب‌پذیری کشف‌شده، خط‌مشی مسئول افشای آسیب‌پذیری را دنبال نموده و از اشتراک‌گذاری جزئیات خاص در عموم خودداری کردیم و به کاربران زمان کافی برای اعمال پچ را ‌دادیم. این رویکرد همچنین برای جلوگیری از اکسپلویت بیشتر توسط عوامل تهدید در نظر گرفته شده است. گوگل با مسدود کردن detankzone[.]com و سایر وب‌سایت‌های مرتبط با این کمپین، اقدامات بیشتری انجام داد و اطمینان داد هر کسی که تلاش می‌کند به این سایت‌ها دسترسی پیدا کند - حتی بدون محصولات ما - در مورد ماهیت مخرب آنها هشدار داده می‌شود.

در حالی که ما به درخواست گوگل برای یک دوره افشای مشخص احترام گذاشتیم، مایکروسافت در 28 می 2024 یک پست وبلاگی با عنوان Moonstone Sleet به عنوان بازیگر جدید تهدید کره شمالی با کوله‌باری از ترفندها ظاهر شد که تا حدی یافته‌های ما را فاش کرد. طبق این وبلاگ، مایکروسافت همچنین از فوریه 2024 کمپین و وبسایت‌های مرتبط را ردیابی کرده بود. با این حال، تجزیه و تحلیل آنها یک نکته کلیدی در کمپین مخرب را نادیده گرفت: وجود سوء استفاده از مرورگر و این واقعیت که این یک مشکل با شدت بالا بود- یک روز صفر. در این گزارش، آسیب‌پذیری‌های مورد سوء استفاده مهاجمین و بازی‌ای که آنها به‌عنوان طعمه استفاده می‌کردند را با جزئیات بررسی می‌کنیم (خطر اسپویل: ما باید سرور خود را برای این بازی آنلاین توسعه می‌دادیم).

اکسپلویت

وبسایت مورد استفاده مهاجمین به عنوان پوششی برای کمپین خود در TypeScript/React توسعه داده شد و یکی از فایل های index.tsx آن حاوی قطعه کوچکی از کد بود که اکسپلویت گوگل کروم را بارگیری و اجرا می‌کرد. این اکسپلویت حاوی کد دو آسیب‌پذیری است: اولی برای به دست آوردن توانایی خواندن و نوشتن حافظه پردازش کروم از جاوا اسکریپت و دومی برای دور زدن سندباکس V8 تازه معرفی‌شده استفاده می‌شود.

اولین آسیب‌پذیری (CVE-2024-4947)

قلب هر مرورگر وب، موتور جاوا اسکریپت آن است. موتور جاوا اسکریپت گوگل کروم V8 نامیده می‌شود - موتور جاوا اسکریپت منبع باز خودِ گوگل. برای مصرف حافظه کمتر و حداکثر سرعت، V8 از یک خط لوله کامپایل جاوا اسکریپت نسبتاً پیچیده استفاده می‌کند که در حال حاضر از یک مفسر و سه کامپایلر JIT تشکیل شده. هنگامی که V8 شروع به اجرای جاوا اسکریپت می‌کند، ابتدا اسکریپت را در بایت کد کامپایل کرده و با استفاده از مفسری به نام Ignition آن را اجرا می‌نماید. ایگنیشن یک ماشین مبتنی بر رجیستر با چندین صد دستورالعمل است. در حین اجرای بایت کد، V8 بر رفتار برنامه نظارت کرده و ممکن است برخی از توابع را برای عملکرد بهتر JIT کامپایل کند. بهترین و سریع‌ترین کد توسط TurboFan تولید می‌شود، یک کامپایلر بسیار بهینه با یک اشکال – تولید کد زمان زیادی می‌برد. با این حال، تفاوت در عملکرد بین Ignition و TurboFan به قدری قابل توجه بود که یک کامپایلر جدید غیربهینه JIT در سال 2021 به نام Sparkplug معرفی شد که تقریباً بلافاصله بایت کد را در کد ماشین معادل کامپایل کرد.  کد تولیدشده توسط Sparkplug سریعتر از مفسر اجرا می‌شود، اما شکاف عملکردی بین کدهای تولید شده توسط Sparkplug و TurboFan همچنان زیاد بود. به همین دلیل، در کروم 117 (منتشر شده در سه ماهه چهارم 2023)، توسعه دهندگان یک کامپایلر بهینه‌سازی جدید به نام Maglev را معرفی کردند که هدف آن تولید کد خوب با سرعت کافی با انجام بهینه‌سازی صرفاً بر اساس بازخورد مفسر بود.

 در این کد می‌بینیم که ابتدا به متغیر صادراتی exportedVar ماژول moduleImport دسترسی پیدا  و سپس چنیش خالی می‌سازد و فرهنگ لغت arrHolder را ایجاد می‌کند. با این حال، به نظر می‌رسد که هیچ کار واقعی با آنها انجام نمی‌شود، آنها فقط توسط ماشه تابع برگردانده می‌شوند. و سپس اتفاق جالبی می‌افتد - تابع f اجرا می‌شود تا زمانی که صحیح و حقیقی بازگردد. با این حال، این تابع تنها در صورتی صحیح برمی‌گرددکه بتواند متغیر صادر شده moduleImport.exportedVar را روی مقدار «3.79837e-312» تنظیم کند، و اگر استثنایی به این دلیل رخ دهد، تابع f «false» را برمی‌گرداند. چطور می‌شود اجرای همان عبارت باید همیشه «غلط» برگردد تا بالاخره بازگشت «صحیح» داشته باشد؟ اگر نگاهی به بایت کد تولیدشده برای این عبارت توسط Ignition و کد کنترل کننده دستورالعمل SetNamedProperty بیندازیم، که قرار است این متغیر را روی مقدار "3.79837e-312"  تنظیم کند، می‌بینیم که همیشه استثنایی در کار است- طبق مشخصات ECMAScript، ذخیره‌سازی در یک شی ماژول همیشه یک خطا در جاوا اسکریپت است.

اما اگر منتظر بمانیم تا این بایت کد بارها اجرا شود و V8 تصمیم بگیرد آن را با استفاده از کامپایلر Maglev کامپایل کند، خواهیم دید که کد ماشین حاصل استثنایی ایجاد نمی‌کند، بلکه در واقع این ویژگی را در جایی در شیء moduleImport تنظیم می‌کند. این به دلیل عدم وجود بررسی ذخیره‌سازی به صادرات ماژول است - که آسیب پذیری CVE-2024-4947 است (در اینجا می‌توانید راه‌حل را پیدا کنید). مهاجمین چگونه از آن سوء استفاده می‌کنند؟ برای پاسخ به این موضوع، باید درک کنیم که اشیاء جاوا اسکریپت چگونه در حافظه نمایش داده می‌شوند. تمام اشیاء JS با یک اشاره‌گر به یک شیء خاص به نام Map  (همچنین به عنوان HiddenClass شناخته می‌شود) شروع می‌شوند که اطلاعات متا در مورد شیء را ذخیره و ساختار آن را توصیف می‌کند. این شامل نوع شیء (ذخیره شده با آفست +8)، تعداد خصوصیات و غیره است.

ماژول moduleImport در حافظه به عنوان یک شیء JSReceiver نمایش داده می‌شود که عمومی ترین شی JS است و برای انواعی که می‌توان برای آنها ویژگی ها تعریف کرد استفاده می‌شود. این شامل یک اشاره‌گر به چینش خصوصیات ( PropertyArray) ) می‌شود که اساساً یک شیء JS معمولی از نوع FixedArray با نقشه خاص خود است. اگر در عبارت moduleImport.exportedVar = 3.79837e-312; moduleImport یک ماژول نبود، بلکه یک شی معمولی بود، کد خاصیت #0 را در آن آرایه تنظیم می‌کرد و با یک افست +8 می‌نوشت. با این حال، از آنجایی که یک ماژول است و یک باگ وجود دارد، کد این ویژگی را تنظیم  و با یک آفست +0 نوشته و شی Map را با شیء ارائه‌شده بازنویسی می‌کند.

از آنجایی که 3.79837e-312 یک عدد ممیز شناور است، به یک مقدار 64 بیتی تبدیل می‌شود (طبق استاندارد IEEE 754)و در یک شیء HeapNumber JS با آفست +4 ذخیره می شود. این به مهاجمان اجازه می‌دهد تا نوع خود را برای شیء PropertyArray تنظیم کنند و باعث سردرگمی نوع شوند. تنظیم نوع روی 0xB2 باعث می‌شود که V8 با PropertyArray به عنوان PropertyDictionary رفتار کند که خرابی حافظه را به همراه دارد زیرا اشیاء PropertyArray و PropertyDictionary اندازه‌های متفاوتی دارند و فیلد kLengthAndHashOffset PropertyDictionary خارج از محدوده PropertyArray قرار می‌گیرد. اکنون مهاجمین باید چیدمان حافظه مناسبی داشته باشند و چیزی مفید را خراب کنند. آنها پشته را یکپارچه و اقداماتی را انجام می‌دهند که می‌توانید در تابع ماشه مشاهده کنید.

آنچه در این تابع اتفاق می‌افتد به شرح زیر است:

•         برای تخصیص PropertyArray moduleImport به متغیر ماژول صادر شده moduleImport.exportedVar دسترسی دارد.
•         یک آرایه خالی با دو عنصر ایجاد می‌کند.
•         با حذف عناصر از این آرایه، شیئی که برای ذخیره عناصر استفاده می‌شود، مجدداً تخصیص داده می‌شود و طول valaArray را 0 می‌کند. این مرحله مهمی است زیرا برای بازنویسی طول whiteArray با هش PropertyDictionary، طول/هش باید برابر با 0 باشد.
•         تابع ماشه فرهنگ لغت arrHolder را با دو شی ایجاد می‌کند. این مرحله به دنبال ایجاد خالی آرایه انجام می شود تا به نشانگرهای این دو شیء دسترسی پیدا کرده و در صورت خراب شدن طول خالی آرایه بازنویسی شوند. اولین شی، xxarr: doubleArray برای ساختن یک اولیه برای دریافت آدرس اشیاء JS استفاده می‌شود. شی دوم، xxab: fakeArrayBuffer برای ساختن یک اولیه برای دسترسی خواندن/نوشتن به کل فضای آدرس فرآیند کروم استفاده می‌شود.
•         سپس، تابع ماشه، تابع f را اجرا می‌کند تا زمانی که توسط Maglev کامپایل شود، و نوع PropertyArray را بازنویسی می‌کند تا به عنوان یک شی PropertyDictionary در نظر گرفته شود.
•         اجرای WeakRef (moduleImport) جدید، محاسبه هش PropertyDictionary را آغاز می‌کند و طول خالی آرایه با مقدار هش بازنویسی می‌شود.
•         تابع ماشه، اشیایی را که حاوی خالی آرایه و arrHolder هستند برمی گرداند که می‌توان آنها را با خالی آرایه بازنویسی کرد.

پس از این، اکسپلویت دوباره از Maglev سوء استفاده می‌کند، یا بهتر است بگوییم این واقعیت که کد را بر اساس بازخورد جمع آوری‌شده توسط مفسر بهینه می‌کند. این اکسپلویت از Maglev برای کامپایل تابعی استفاده می‌کند که یک مقدار مضاعف را از یک آرایه به دست آمده با استفاده از arrHolder.xxarr بارگذاری می‌کند. هنگامی که این تابع کامپایل می شود، مهاجمین می‌توانند اشاره گر را به آرایه‌ای که با استفاده از arrHolder.xxarr از طریق valaArray[5] به دست آمده بازنویسی و از این تابع برای دریافت آدرس اشیاء JS استفاده کنند. به طور مشابه، مهاجمین از arrHolder.xxab برای کامپایل تابعی استفاده می‌کنند که ویژگی‌های خاصی را تنظیم کرده و طول یک شی دیگر از نوع ArrayBuffer را همراه با اشاره‌گر به داده‌های آن  backing_store_ptr) ) بازنویسی می‌کند. این زمانی ممکن می‌شود که اشاره‌گر به شی قابل دسترسی با استفاده از  arrHolder.xxab از طریق valaArray[6] با اشاره گر به ArrayBuffer جایگزین شود. این به مهاجمین امکان دسترسی خواندن و نوشتن به کل فضای آدرس فرآیند کروم را می‌دهد.

آسیب‌پذیری دوم (دور زدن سندباکس V8)

در این مرحله، مهاجمین می‌توانند مموری را از جاوا اسکریپت بخوانند و بنویسند اما برای دور زدن سندباکس تازه معرفی‌شده‌ی V8 نیاز به آسیب‌پذیری اضافی دارند. این سندباکس تماماً بر پایه نرم‌افزار است و ویژگی اصلی‌اش ایزوله کردن مموری V8 به طوریست که مهاجمین نتوانند به سایر اجزای موری دسترسی داشته باشند و کد را اجرا کنند. چگونه این کار را انجام می‌دهد؟ ممکن است متوجه شده باشید که تمام نشانگرهای بخش قبل 32 بیت هستند. این به این دلیل نیست که ما در مورد یک فرآیند 32 بیتی صحبت می‌کنیم.  این یک فرآیند 64 بیتی است، اما نشانگرها 32 بیت هستند زیرا V8 از چیزی به نام فشرده سازی اشاره‌گر استفاده می‌کند.

اشاره‌گرها به طور کامل ذخیره نمی‌شوند، بلکه فقط به عنوان قسمت‌های پایینی‌شان ذخیره می‌شوند، یا می‌توانند به عنوان یک افست 32 بیتی از برخی آدرس های "پایه" نیز دیده شوند. قسمت بالایی (آدرس "پایه") در ثبات های CPU ذخیره و توسط کد اضافه می‌شود. در این حالت، مهاجمین نباید قادر به دریافت نشانگرهای واقعی از حافظه جدا شده باشند و هیچ راهی برای به دست آوردن آدرس برای صفحات پشته و کد JIT نداشته باشند. آسیب‌پذیری این است که ماشین مجازی تعداد ثابتی از رجیسترها و یک آرایه اختصاصی برای ذخیره آنها دارد، اما شاخص‌های رجیستر از بدنه‌های دستورالعمل رمزگشایی می‌شوند و بررسی نمی‌شوند. این به مهاجمین اجازه می‌دهد تا خارج از محدوده آرایه ثبت به حافظه دسترسی داشته باشند.

به طور تصادفی، اشاره‌گرهای output_registers و output_register_count درست در کنار آرایه رجیستر قرار دارند. این به مهاجمین اجازه می‌دهد تا با کمک کد عملیاتی SUCCEED، حافظه را خارج از سندباکس V8 بخوانند و بنویسند. مهاجمین از این برای بازنویسی کد JIT با پوسته کد و اجرای آن استفاده می‌کنند. این مشکل (330404819) در مارس 2024 ارسال و برطرف شد. مشخص نیست که آیا این یک برخورد باگ بود و مهاجمین ابتدا آن را کشف و در ابتدا از آن به عنوان یک آسیب‌پذیری 0 روزه سوء استفاده کردند یا اینکه در ابتدا به عنوان یک آسیب‌پذیری 1 روزه مورد سوء استفاده قرار گرفتند.

شِل کد

در این مرحله، مهاجمین برای فرار از فرآیند کروم و دسترسی کامل به سیستم به آسیب‌پذیری‌های بیشتری نیاز دارند. در بهترین شیوه‌های مهاجمین پیشرفته، آنها اعتبارسنجی را به شکل یک کد پوسته اجرا می‌کنند که تا حد امکان اطلاعات را جمع‌آوری کرده و آن را به سرور ارسال می‌کند تا تصمیم بگیرد که آیا مرحله بعدی (اکسپلویت دیگر) را ارائه کند یا خیر. این تصمیم بر اساس اطلاعات زیر گرفته می‌شود:

اطلاعات CPUID  (فروشنده، نام پردازنده، و غیره)، اینکه آیا در VM اجرا می‌شود یا نه، نسخه و ساخت سیستم عامل، تعداد پردازنده ها، تعداد تیک ها، نوع محصول سیستم عامل، اینکه آیا در حال اشکال‌زدایی است. یا نه، مسیر فرآیند، اطلاعات نسخه فایل ماژول‌های سیستم، اطلاعات نسخه فایل فایل اجرایی فرآیند، و جدول سیستم عامل SMBIOS.  تا زمانی که حمله را تجزیه و تحلیل کردیم، مهاجمین قبلاً این اکسپلویت را از وب‌سایت decoy حذف کرده بودند و ما را از دستیابی آسان به مرحله بعدی حمله باز می‌داشتند. در کسپرسکی ما دارای فناوری‌هایی هستیم که به ما امکان کشف و کمک به رفع تعداد زیادی آسیب‌پذیری افزایش امتیاز 0 روزه را می‌دهند که توسط مهاجمین پیشرفته در کمپین‌های مختلف بدافزار در طول سال‌ها مورد سوء استفاده قرار گرفته‌اند. با این حال، در این مورد خاص، باید منتظر حمله بعدی می‌بودیم تا بتوانیم مرحله بعدی آن را استخراج کنیم. تصمیم گرفتیم منتظر نمانیم و ترجیح دادیم بگذاریم گوگل اکسپلویت اولیه مورد استفاده برای اجرای کد از راه دور در گوگل کروم را اصلاح کند.

فعالیت اجتماعی

چیزی که هرگز ما را تحت تاثیر قرار نمی‌دهد این است که Lazarus APT چقدر تلاش می‌کند تا کمپین های مهندسی اجتماعی خود را انجام دهد. برای چندین ماه، مهاجمین در حال ساختن حضور خود در رسانه های اجتماعی بودند، به طور مرتب در X  (توئیتر سابق) از چندین حساب پست می‌گذاشتند و بازی خود را با محتوای تولیدشده توسط هوش مصنوعی و طراحان گرافیکی تبلیغ می‌کردند. یکی از تاکتیک‌هایی که مهاجمین استفاده کردند تماس با چهره‌های با نفوذ در فضای ارزهای دیجیتال بود تا آنها را وادار به تبلیغ وب‌سایت مخرب خود کنند و به احتمال زیاد آنها را نیز به خطر بیندازند. فعالیت مهاجمین به X محدود نمی‌شد - آنها همچنین از وبسایت‌های حرفه‌ای طراحی‌شده با بدافزار اضافی، حساب‌های برتر در لینکدین و نیزه فیشینگ از طریق ایمیل استفاده کردند.

بازی

چیزی که در این حمله توجه ما را به ویژه جلب کرد این بود که وبسایت مخربی که با استفاده از روز صفر گوگل کروم به بازدیدکنندگانش حمله می‌کرد، از آنها دعوت کرد تا نسخه بتا یک بازی رایانه‌ای را دانلود و امتحان کنند. به عنوان طرفداران بزرگ بازی های رایانه‌ای، بلافاصله خواستیم آن را امتحان کنیم. آیا مهاجمین می‌توانستند یک بازی واقعی برای این کمپین ایجاد کنند؟ آیا این می‌تواند اولین بازی کامپیوتری باشد که توسط یک بازیگر تهدید ساخته شده است؟  detankzone.zip را دانلود کردیم و درست به نظر می‌رسید: آرشیو 400 مگابایتی حاوی یک ساختار فایل معتبر از یک بازی توسعه یافته در Unity بود. ما منابع بازی را باز کردیم و لوگوهای DeTankZone، عناصر HUD و بافت‌های مدل سه بعدی را پیدا کردیم.

مصنوعات اشکال‌زدایی نشان می‌داد بازی توسط مهاجمین کامپایل شده  است. تصمیم گرفتیم امتحانش کنیم. پس از معرفی لوگوی بازی، با یک منوی شروع بازی آنلاین معمولی مواجه شدیم که از ما می‌خواست اعتبار حساب معتبر را برای دسترسی به بازی وارد کنیم.  سعی کردیم با استفاده از نام‌ها و گذرواژه‌های رایج حساب وارد شویم، و سپس تلاش کردیم حساب خودمان را از طریق بازی و وب‌سایت ثبت کنیم - اما هیچ‌چیز درست پیش نرفت. آیا واقعاً این تمام چیزی است که این بازی ارائه می‌دهد؟ شروع به مهندسی معکوس کد بازی کردیم و متوجه شدیم که محتوای بیشتری فراتر از این منوی شروع در دسترس است. کد مسئول ارتباط با سرور بازی را پیدا و مهندسی معکوس آن را نیز آغاز کردیم. بازی برای استفاده از سروری که در api.detankzone[.]com اجرا می‌شود، کدگذاری سختی داشت، که به وضوح کار نمی‌کرد. اما ما واقعاً می‌خواستیم این بازی را بررسی کنیم! چه باید می‌کردیم؟ البته تصمیم گرفتیم سرور بازی خودمان را توسعه دهیم.

ابتدا متوجه شدیم که بازی از پروتکل Socket.IO برای ارتباط با سرور استفاده می‌کند، بنابراین کتابخانه python-socketio را برای توسعه سرور خود انتخاب کردیم. سپس تابعی را با لیستی از نام‌های دستورات پشتیبانی شده (نام رویداد) پیدا و نحوه مبهم شدن آنها را مهندسی معکوس کردیم. پس از آن، نحوه کدگذاری داده ها را مهندسی معکوس کردیم: معلوم شد که یک JSON رمزگذاری شده با AES256 و کدگذاری‌شده با Base64 است. برای کلید AES از رشته  Full Stack IT Service 198703Game استفاده می‌کند، در حالیکه رشته  MatGoGameProjectبرای IV استفاده می‌شود. امیدوار بودیم که این اطلاعات هویت سازندگان بازی را فاش کند، اما جستجوی گوگل نتیجه ای نداشت. در نهایت، قالب داده‌ها را برای چند دستور مهندسی معکوس کردیم، آن‌ها را روی سرور خود پیاده‌سازی و آدرس سرور خود را با آدرس سرور خود جایگزین کردیم. موفقیت! بعد از این همه ما توانستیم وارد بازی شویم و با ربات‌ها بازی کنیم!

بله، معلوم شد که یک بازی واقعی است! ما کمی آن را بازی کردیم و سرگرم کننده بود - ما را به یاد برخی از بازی های نرم افزاری از اوایل دهه 2000 می‌انداخت. قطعا ارزش تلاش را دارد. بافت ها کمی چسبناک به نظر می‌رسیدند و خود بازی بسیار شبیه به یک آموزش محبوب Unity است، اما اگر Lazarus این بازی را خودش توسعه داده بود نوار جدیدی برای آماده سازی حمله تعیین می‌کردند. اما کاشف بعمل آمد که کد منبع این گیم از توسعه‌دهنده‌های اصلی‌اش کِش رفته شده!

گیم اورجینال

یک بازی قانونی پیدا کردیم که به عنوان نمونه اولیه برای نسخه مهاجم عمل می‌کرد - DeFiTankLand (DFTL) نام دارد. مطالعه چت تلگرام توسعه‌دهندگان به ما کمک کرد تا  جدول زمانی حمله بسازیم. در 20 فوریه 2024، مهاجمین کمپین خود را آغاز و بازی خود را در X تبلیغ کردند. دو هفته بعد، در 2 مارس 2024، قیمت ارز DeFiTankLand، سکه DFTL2، کاهش یافت و توسعه‌دهندگان بازی در تلگرام خود اعلام کردند که کیف پول سرد هک و 20000 دلار سکه DFTL2 به سرقت رفته بود. توسعه‌دهندگان این را گردن نفوذی‌ها انداختند. حالا نفوذی در کار بوده یا نه به هر حال ما ظن داشتیم کار، کار لازاروس است و پیش از سرقت سکه‌ها اولین بار کد منبع گیم را سرقت کردند، همه لوگوها و ارجاعات به DeFiTankLand را تغییر داده و از آن برای موجه‌تر جلوه دادن کمپین خود استفاده کردند.

نتیجه‌گیری

لازاروس یکی از فعال‌ترین و پیچیده‌ترین عاملین APT است و دستیابی مالی همچنان یکی از بالاترین انگیزه‌هاست. درطول سال‌ها، بسیاری از این حملات را در صنعت رمزارز رو کردیم و یک چیز بین همه‌شان مشترک است: این حملات از بین نخواهند رفت. تاکتیک‌های مهاجمین در حال توسعه و تکامل است و مدام دارند با نقشه‌های جدید و مهندسی معکوس‌های پیچیده آپدیت می‌شوند. لازاروس همین الانش هم با موفقیت استفاده از هوش مصنوعی مولد را شروع کرده و ما پیش‌بینی‌مان این است که حتی با استفاده از این فناوری دست به اجرای حملات پرجزئیات‌تر و پیشرفته‌تری خواهند زد. آنچه حمله لازاورس را مشخصاً خطرناک می‌کند، استفاده مکررشان از اکسپلویت‌های روز صفر است.

کلیک ساده روی یک لینک شلکه اجتماعی یا ایمیل می‌تواند به دستکار کامل کامپیوتر شخصی یا شبکه سازمانی منجر شود. از حیث تاریخی، نیمی از باگ‌های کشف‌شده یا اکسپلویت‌شده در گوگل کروم و سایر مرورگرهای وبی کامپایلرهای خود را تحت‌الشعاع قرار دادند. تغییرات فاحش در پایه کد مرورگر وبی و معرفی کامپایلرهای جدید JIT ناگزیر به ایجاد کلی آسیب‌پذیری جدید منجر می‌شود. آنچه کاربران نهایی باید برای این مسئله انجام دهند چیست؟ خوب، راستش گوگل که به افزودن کامپایلرهای جدید JIT ادامه خواهد داد و همچنین اج مایکروساف هم هرگز از آن استفاده نخواهد کرد. اما منصفانه است که بگوییم سندباکس تازه‌معرفی‌شده V8 ممکن است در متوقف کردن اکسپلویت باگ‌های داخل کامپایلرها موفق عمل کند. وقتی کمی بالغ‌تر شد، شاید اکسپلویت گوگل کروم با JIT به اندازه اکسپلویت مایکروسافت اج بدون آن سخت شود.

شاخص‌های دستکاری

اکسپلویت

B2DC7AEC2C6D2FFA28219AC288E4750C
E5DA4AB6366C5690DFD1BB386C7FE0C78F6ED54F
7353AB9670133468081305BD442F7691CF2F2C1136F09D9508400546C417833A

گیم

8312E556C4EEC999204368D69BA91BF4
7F28AD5EE9966410B15CA85B7FACB70088A17C5F
59A37D7D2BF4CFFE31407EDD286A811D9600B68FE757829E30DA4394AB65A4CC

دامنه‌ها

detankzone[.]com
ccwaterfall[.]com

کسپرسکی آنلاین (ایدکو)

کسپرسکی اسم یکی از بزرگترین شرکتهای امنیتی و سازنده آنتی ویروس است که برخی از کاربران اشتباهاً این شرکت و محصولات آنتی ویروس آن را با عناوینی نظیر کسپرسکای،کاسپرسکی، کسپراسکای، کسپراسکای، و یا کاسپراسکای نیز می‌شناسد. همچنین لازم به ذکر است مدیرعامل این شرکت نیز یوجین کسپرسکی نام دارد.