مجرمان سایبری برای توزیع بدافزارهاشون به پکرها متکی هستن. پکرها که در انجمن های هک با نام Crypter یا FUD هم شناخته میشن ، شناسایی کدهای مخرب برای محصولات امنیتی سخت میکنن.
یکی از ویژگی های پکرهای Packer-as-a-Service تجاری اینه که مهم نیست ، پیلود چی هستش. یعنی ممکنه یه فایل سالم باشه که برای سختتر شدن فرایند کرک بهش بدن یا نه صرفا یه بدافزار باشه.
ویژگی دیگه این سرویسها اینه که ساختار پکرها بصورت منظم در حال تغییر هستش و در نتیجه شناسایی بدافزارها رو برای محصولات آنتی ویروس سخت میکنه.
یکی از این پکرهای Packer-as-a-Service تجاری ، TrickGate هستش که سالها با تغییرات و بهبودهایی که در خودش ایجاد میکنه ، خودش از دید برنامه های آنتی ویروس نامرئی میکنه.
محققای چک پوینت یه بررسی فنی روی این سرویس انجام دادن و یه گزارش فنی منتشر کردن که اینجا بخش هایی از اون رو بررسی میکنیم.
اولین چیزی که در خصوص این پکر گفتن اینه که این پکر استاد تغییر قیافه هستش. یعنی تو این مدت با تغییراتی که داده ، با نامهای متنوعی از جمله TrickGate و Emotet’s packer و new loader و Loncom و NSIS-based crypter و … ارائه شده.
فعالیت 6 ساله TrickGate:
این پکر اولین بار در اواخر سال 2016 مشاهده شده. اون زمان برای پک کردن باج افزار Cerber ازش استفاده کرده بودن. از اون زمان به بعد این پکر در انواع بدافزارها مانند باج افزارها ، RATها ، بدافزارهای بانکی ، info-stealer ها و ماینرها استفاده شده. همچنین برخی گروههای APT هم از این پکر برای پک کردن کدهاشون استفاده کردن.
این پکر در برخی بدافزارهای شناخته شده از جمله ، Cerber و Trickbot و Maze و Emotet و REvil و CoinMiner و Cobalt Strike و DarkVNC و BuerLoader و HawkEye و NetWire و AZORult و Formbook و Remcos و Lokibot و AgentTesla مورد استفاده قرار گرفته.
نحوه توزیع TrickGate :
محققای چک پوینت در دو سال گذشته ، 40 تا 650 حمله در هفته رو رصد کردن که از این پکر استفاده میکردن. بازیگران تهدیدی که از این پکر در حملاتشون استفاده کردن ، عمدتا مراکز تولیدی رو هدف قرار دادن ، اما بخش هایی مانند آموزش ، مالی ، تجاری و بهداشت هم مورد هدف قرار گرفته.
این حملات در سراسر جهان توزیع شده اما در تایوان و ترکیه افزایش یافته. در دو ماه گذشته بدافزار Formbook با توزیع 42 درصدی بیشترین استفاده کننده از این پکر بوده.
مسیر حمله:
در ادامه به بررسی مسیر حمله معمول در حملاتی که از TrickGate استفاده میکنن پرداخته شده.
دسترسی اولیه : دسترسی اولیه بسته به بازیگر تهدید متفاوت هستش، اما عمدتا از طریق ایمیلهای فیشینگ حاوی پیوست مخرب یا انتشار لینکهای مخرب پخش شدن.
فایلهای دسترسی اولیه : در مرحله اولیه اغلب از فایلهای اجرایی آرشیو شده (فشرده)، استفاده میشه اما موارد مختلفی از جمله موارد زیر رو رصد کردن :
- آرشیوی : 7Z و ACE و ARJ و BZ و BZ2 و CAB و GZ و IMG و ISO و IZH و LHA و LZ و LZH و R00 و RAR و TAR و TGZ و UU و UUE و XZ و Z و ZIP و ZIPX و ZST
- اجرایی: BAT و CMD و COM و EXE و LNK و PIF و SCR
- سند: DOC و DOCX و PDF و XLL و XLS و XLSX و RTF
لودر شلکد: مرحله دوم، لودر شلکد هستش که مسئولیت رمزگشایی و لوود شلکد رو به عهده داره. لودر شلکد در سه زبان سی و NSIS script و AutoIT script توسعه داده شده.
شلکد: شلکد بخش اصلی پکر هستش که مسئولیت رمزگشایی پیلود و تزریق اون به یه پروسس جدید هستش.
پیلود: پیلود کد مخرب واقعی هستش که قراره یه کار مخرب رو انجام بده. بسته به بازیگر تهدید میتونه یه باج افزار باشه یا ماینر و … .
در ادامه چند مورد از بردارهای حمله ای که اخیرا مشاهده کردن رو میبینید :
لودر شلکد:
لودر شلکد شامل یه تابع هستش که مسئولیت رمزگشایی و اجرای شلکد در حافظه رو داره. در کل مراحل زیر رو طی میکنه :
- شلکد رمزگذاری شده رو میخونه. شلکد میتونه داخل یه فایل یا در بخش rdata یا بعنوان resource باشه.
- در حافظه یه فضایی به اندازه شلکد اختصاص میده. این کار اغلب با VirtualAlloc انجام میشه.
- شلکد رمزگشایی میشه.
- شلکد اجرا میشه. اینکار یا از طریق فراخوانی مستقیم یا از طریق توابع callback انجام میشه.
لودر شلکد ، در نسخه های جدیدتر TrickGate از مکانیسم Callback Functions ویندوز سوء استفاده میکنه. لودر از یسری API call بومی که یه آدرس مموری رو به عنوان آرگومان callback function ، میگیرن ، استفاده میکنه. حالا به جای Callback Function ، آدرس شلکد خودشون رو پاس میدن. در نتیجه وقتی ویندوز به قسمت registered event ها میرسه ، DriverCallback شلکد رو اجرا میکنه. در تصاویر بالا EnumTimeFormatsA و EnumSystemCodePagesW حاوی این مطلب هستش.
شباهت شلکد و تعطیلات TrickGate :
معمولا وقتی شباهت کد در بین خانواده های مختلف بدافزارهای غیرمرتبط شناسایی میشه ، نشون میده که یا بازیگران تهدید از یه منبع مشترک کپی کردن یا کد بینشون به اشتراک گذاشته شده. برای یه مدت طولانی محققا متوجه یه تکنیک منحصر به فرد تزریق کد با استفاده مستقیم از kernel syscall ها شدن، اما فک کردن که این صرفا یه اشتراک کد هستش. اما چیزی که باعث شده بیشتر شک کنن که این تکنیک تحت کنترل یه بازیگر تهدید هستش ، این بوده که تو یسری بازه زمانی ، TrickGate فعالیت خودش متوقف کرده و اینا دیدن بقیه بازیگران تهدید هم دیگه از این تکنیک استفاده نمیکنن.
تو وقفه سه ماهه بین 13 ژوئن 2022 تا 26 سپتامبر 2022 وقت گذاشتن تا شلکد رو بیشتر بررسی کنن. برای این منظور شروع به بررسی نمونه های مختلف در طول زمان کردن.
بررسی اینجوری بوده که دو نمونه مختلف ، یکی متعلق به بدافزار Remcos برای سال 2022 و دیگری متعلق به بدافزار CoinMiner برای سال 2017 ، تا جایی که شلکد تو حافظه رمزگشایی میشد ، پیش بردن و بعدش اونو در دیسک ذخیره کردن. بعدش با ابزار BinDiff مقایسه کردن. متوجه شدن که تقریبا 50 درصد شلکد مشابه هستش. اینکه پکر یه شلکد 5 کیلوبایتی ، در طول 5 سال ، 50 درصدش رو حفظ کرده براشون عجیب بوده. در ادامه بررسی کردن که چه تغییراتی در طول این مدت انجام گرفته. (کشف این تغییرات تقریبا نشون دهنده روش زنده بودن پکر در طول این مدت هستش)
برای این بررسی ، نمونه هایی از 6 سال گذشته رو تحلیل کردن. همونطور که در نمودار زیر قابل مشاهده هست ، تغییرات کوچیکی رخ داده. نمودار سمت چپ برای سالهای 2016 تا 2020 هستش که 90 درصد شبهات رو نشون میده. نمودار سمت راست برای سال 2019 تا 2022 هستش که شباهت زیادی بیشنون هست اما با نسخه اصلی (سمت چپ) شباهت کمتری رو داره.
برای بررسی موارد زیر رو بدست آوردن تا نویز بین نمونه ها رو کم کنن :
- کامپایلرهای مختلف
- مبهم سازها
- ماژولهای دور زدن محصولات امنیتی
- ماژولهای پرسیست
- ترتیب قرار گرفتن توابع
- متغییرهای محلی و ساختارها
با حذف موارد بالا ، خواستن به عملکرد اصلی شلکد برسن. در نتیجه متوجه شدن نویسنده پکر در طول زمان، شلکد رو حفظ کرده و فقط یسری اجزاء رو تغییر یا بهش اضافه کرده.
اجزاء شلکد:
همونطور که بالا اشاره شد ، شلکد در طول زمان بروزرسانی شده اما عملکرد اصلی اون حفظ شده. یک نمای کلی از اجزای سازنده شلکد بصورت زیر هستش :
- تحلیل (resolve) API hash
- لوود پیلود در حافظه و رمزگشایی اون
- تزریق مستقیم با استفاده از kernel call ها
- بصورت دستی یه کپی تازه از ntdll رو مپ میکنه.
- شماره kernel syscall رو بصورت داینامیک بدست میاره.
- syscallهای مورد نظرش رو فراخونی میکنه
- پیلود رو تزریق و اجرا میکنه.
استفاده از تکنیک API hashing :
داخل کدهای پکر هیچ رشته ثابتی وجود نداره. بیشتر اوقات این پکر با استفاده از کدهای تمیز و debug string ها باعث جلوگیری از آنالیز کد میشه. برای پنهون کردن رشته ها و اهداف اونها ، این پکر از تکنیک API hashing استفاده میکنه.() در این تکنیک تمام APIهای ویندوز با یه شماره هش ، مخفی میشن. تا ژانویه 2021 از CRC32 برای هش کردن استفاده میکردن. اما در نسخه های جدیدتر از یه الگوریتم اختصاصی استفاده کردن. در زیر معادل پایتونی هشهای مورد استفاده در 2 سال گذشته رو مشاهده میکنید.
|
1 2 3 4 5 |
def hash_str_ror1(str): h = 8998 for c in str: h += ord(c) + (((h >> 1) & 0xffffffff) | ((h << 7) & 0xffffffff)) return h & 0xffffffff |
|
1 2 3 4 5 |
def hash_str21(str): h = 8998 for c in str: h = ord(c) + (0x21 * h) return h & 0xffffffff |
جدول زیر هم نام Kernel32 API و هش معادل اونها در نمونه های بررسی شده هستش:
| API NAME | CRC32 | hash_str_ror1 | hash_str21 |
| CloseHandle | 0xB09315F4 | 0x7fe1f1fb | 0xd6eb2188 |
| CreateFileW | 0xA1EFE929 | 0x7fe63623 | 0x8a111d91 |
| CreateProcessW | 0x5C856C47 | 0x7fe2736c | 0xa2eae210 |
| ExitProcess | 0X251097CC | 0x7f91a078 | 0x55e38b1f |
| GetCommandLineW | 0xD9B20494 | 0x7fb6c905 | 0x2ffe2c64 |
| GetFileSize | 0xA7FB4165 | 0x7fbd727f | 0x170c1ca1 |
| GetModuleFileNameW | 0XFC6B42F1 | 0xff7f721a | 0xd1775dc4 |
| GetThreadContext | 0x649EB9C1 | 0x7fa1f993 | 0xc414ffe3 |
| IsWow64Process | 0x2E50340B | 0xff06dc87 | 0x943cf948 |
| ReadFile | 0x95C03D0 | 0x7fe7f840 | 0x433a3842 |
| ReadProcessMemory | 0xF7C7AE42 | 0x7fa3ef6e | 0x9f4b589a |
| SetThreadContext | 0x5688CBD8 | 0xff31bf16 | 0x5692c66f |
| VirtualAlloc | 0x9CE0D4A | 0x7fb47add | 0xa5f15738 |
| VirtualFree | 0xCD53F5DD | 0x7f951704 | 0x50a26af |
لوود پیلود در مموری و رمزگشایی اون :
پکر همیشه روش رمزگشایی رو تغییر میده. بنابراین روشهایی که تا الان استفاده شده جواب نمیدن. اغلب نمونه ها از روش های رمزگشایی اختصاصی استفاده میکنن. البته در نمونه های قدیمی تر از RC4 یا APIهای خود ویندوز برای رمزنگاری استفاده میکردن.
تزریق مستقیم با استفاده از kernel call ها :
پس از اینکه پیلود رمزگشایی شد، شلکد به یه پروسس جدید تزریق میشه. بعد از ایجاد پروسس با فلگ create_suspended ، تزریق از طریق یسری kernel call انجام میشه. در زیر ntdll API call ها رو مشاهده میکنید :
- NtCreateSection
- NtMapViewOfSection
- NtUnmapViewOfSection
- NtWriteVirtualMemory
- NtResumeThread
کارهایی که در این مرحله انجام میشه بدین صورت هستش :
- یه کپی جدید از ntdll به مموری مپ میکنه.
- در ntdll جدید مپ شده ، آدرس هش رو بدست بیاره.
- SSN درخواست رو بصورت داینامیکی بدست میاره. (System Service Number)
- با این SSN در کرنل اجرا میکنه :
ماژول تزریق ، ثابت ترین بخش شلکد پکر TrickGate بوده که از سال 2016 حفظ شده.
سه تا از نمونه بدافزارهایی که در گزارش اومده رو برای تحلیل و تمرین بیشتر میتونید از اینجا دانلود کنید.