ترفندهای باجافزار LockFile از رمزگذاری تا دور زدن سیستم‌های امنیتی
LockFile باجافزار جدیدی است که به دنبال کشف آسیب‌پذیری‌های ProxyShell سرورهای Microsoft Exchange در اردیبهشت، در تیر ماه منتشر شد. به نظر می‌رسد که باجافزار LockFile از آسیب‌پذیری‌های ProxyShell برای نفوذ به اهداف بدون وصله در سرورهای Microsoft Exchange استفاده میکند و سپس حمله PetitPotam NTLM برای تحت اختیار گرفتن کنترل دامنه انجام می‌شود.
اخیراً محققان سوفوس (Sophos, Ltd) در مقاله‌ای، باجافزار LockFile را به صورت دقیق مورد تحلیل قرار داده‌اند و در مقاله ای رویکرد جدید آن را در خصوص رمزگذاری فایل‌ها و نحوه تلاش باجافزار برای بی اثر کردن راهکارهای حفاظتی و مبتنی بر آمار نشان میدهند.
در این گزارش که با همکاری شرکت مهندسی شبکه گستر و مرکز مدیریت راهبردی افتای ریاست جمهوری تهیه گردیده، ترجمه مقاله مذکور ارائه شده است.
این مقاله یافته‌های کلیدی زیر را به طور عمیق مورد بحث قرار میدهد:
- باجافزار LockFile هر 16 بایت از یک فایل را رمزگذاری میکند. این روش که “رمزگذاری متناوب” نامیده شده، اولین بار توسط محققان سوفوس کشف شده است. رمزگذاری متناوب از شناسایی باجافزار توسط برخی راهکارهای حفاظتی و امنیتی جلوگیری میکند زیرا سند رمزگذاری شده از نظر آماری بسیار شبیه به نسخه اصلی رمزگذاری نشده آن است.
- همانند باج‌افزارهای WastedLicker و Maze، باجافزار LockFile برای رمزگذاری یک فایل، از نگاشت ورودی/خروجی حافظه (Memory Mapped Input/Output)، استفاده میکند. این تکنیک به باجافزار اجازه میدهد اسناد ذخیره شده را بی‌واسطه در حافظه رمزگذاری کند، لذا از آنجا که ورودی/خروجی دیسک توسط فناوری‌های حفاظتی قابل تشخیص هستند، باجافزار در این روش سیستم‌عامل را مجبور میکند تا اسناد رمزگذاری شده را با حداقل ورودی/خروجی دیسک، بنویسد.
- این باجافزار برای برقراری ارتباط نیازی به اتصال به سرورهای کنترل و فرماندهی (C2) ندارد و این امر منجر به عدم تشخیص آن در راهکارهای امنیتی نصب شده بر روی دستگاهها می‌شود.
- علاوه بر این، LockFile اسناد رمزگذاری شده را به حروف کوچک تغییر نام میدهد و به آنها پسوند lockfile. اضافه میکند و اطلاعیه باج‌گیری HTAو(HTA Ransom Note) آن بسیار شبیه به باجافزار LockBit 2.0 است.
تحقیقات سوفوس، مبتنی بر نمونه‌ای از باجافزار LockFile با هش SHA-256 زیر می‌باشد:
bf315c9c064b887ee3276e1342d43637d8c0e067260946db45942f39b970d7ce
مشخصات این فایل در لینک زیر قابل دریافت است.
اگر شما این نمونه را در آدرس زیر بارگذاری نمایید، متوجه خواهید شد که همانند تصاویر زیر سه تابع و سه بخش دارد.
به نظر می‌رسد که فایل باینری دو بار توسط UPX بسته‌بندی و سپس تغییر شکل داده شده به نحوی که محصول امنیتی نصب شده بر روی دستگاه، قادر به تحلیل ایستای آن نخواهد بود. همچنین، نام بخش‌های اصلی از UPX0 و UPX1 به OPEN و CLSE تغییر داده شده است. اندازه بخش اول به نام OPEN،و592 کیلوبایت (0x94000) است، اما هیچ داده‌ای بجز صفر ندارد. اندازه بخش دوم، یعنی CLSE،و286 کیلوبایت (0x43000) است و سه تابع در صفحه پایانی آن قرار دارند. بقیه داده‌ها، کد رمزگذاری شده است که بعداً رمزگشایی می‌شوند و در بخش OPEN قرار می‌گیرند.
تابع ()entry بسیار ساده است و ()FUN_1400d71c0 را فراخوانی میکند.
تابع ()FUN_1400d71c0، داده بخش CLSE را رمزگذاری میکند و آن را در بخش OPEN قرار میدهد. علاوه بر این توابع و DLLهای مربوطه را تعیین میکند. سپس مقادیر IMAGE_SCN_CNT_UNINITIALIZED_DATA را دستکاری نموده و به کدی که در بخش OPEN قرار دارد، پرش میکند.
از آنجایی که بقیه کد در بخش OPEN بصورت Unpacked می‌باشد، (به عنوان مثال در زمان اجرا تولید می‌شود)، از WinDbg و writemem. برای نوشتن بخش OPEN در دیسک، استفاده می‌شود، لذا کد همانند زیر به صورت ایستا در Ghidra قابل تحلیل می‌شود:
.writemem c:\[redacted]\LockFile\sec_open.bin lockfileexe+1000 L94000
پس از بارگذاری فایل در Ghidra جهت تحلیل، تابع شروع اصلی آن به صورت زیر نمایش داده می‌شود:
تابع فوق، CRT است که یک کتابخانه در حال اجرا به زبان C می باشد و تابع اصلی که در این تحلیل اهمیت داشته باشد، محسوب نمی‌شود. بعد از جستجوی بیشتر به تابع اصلی نیز همانند تصویر زیر می‌رسیم.
محققان در هنگام بررسی، این تابع را به ()main_000861 تغییر نام دادند و آدرس آن را به عنوان مرجع جهت انجام اشکال‌زدایی در WinDbg حفظ کردند. بخش اول، کتابخانه crypto را راه‌اندازی میکند.
در کد فوق، رشته‌هایی همچون “Cryptographic algorithms are disabled after” یافت می‌شود، که به صورت رایگان در Crypto++Library در GitHub به آدرس زیر، در دسترس است، لذا می‌توان این‌گونه نتیجه گرفت که باجافزار LockFile، از این کتابخانه برای توابع رمزنگاری استفاده میکند.
https://github.com/weidai11/cryptopp
سپس جهت جلوگیری از اجرای دوباره باجافزار در یک زمان، یک mutex ایجاد میکند.
سپس یک رشته که پارامتری از تابع ()system است، همانندآنچه در خط 161 نشان داده شده است، رمزگشایی می‌شود.
رشته فوق، پارامتری برای تابع ()system می‌باشد که در خط 161 فراخوانی می‌شود و تمام پروسه‌هایی را که در نامشان vmwp وجود دارد، خاتمه میدهد. بدین منظور، ابزار خط فرمان Windows Management Interface – به اختصار WMI – یا همان WMIC.EXE که در هر فرایند نصب در سیستم‌عامل Windows دخیل است، بکار برده می‌شود. این عمل، برای سایر پروسه‌های تجاری حیاتی مرتبط با نرم‌افزارهای مجازی‌سازی و پایگاه‌داده نیز تکرار می‌شود.
با بکارگیری WMI، این نکته آشکار می‌شود که باجافزار به صورت مستقیم به این نوع از پروسه‌های تجاری حیاتی خاتمه داده شده، مربوط نیست. خاتمه این پروسه‌ها، اعمال هر نوع رمزگذاری را بر روی فایل‌ها/پایگاه‌داده‌های مربوطه تضمین میکند، لذا اکنون این اشیاء آماده رمزگذاری‌های مخرب هستند. کد فوق، تمام حروف مشتق شده از ()GetLogicalDriveString را در خط 692 بازیابی و این عمل را تکرار میکند.
در حلقه، نوع درایو از طریق ()GetDrive Type تشخیص داده می‌شود. هنگامی که این دیسک ثابت است (type three = DRIVE_FIXED در خط 703)، یک Thread جدید (در خطوط 705 و 706) با تابع 0x7F00 به عنوان آدرس شروع ایجاد می‌شود.
تابعی که در 0x7f00 قرار دارد، ابتدا اطلاعیه باج‌گیری HTA را ایجاد میکند. به عنوان مثال، “LOCKFILE-README-[hostname]-[id].hta” را در ریشه درایو (root drive) ایجاد میکند. به جای قرار دادن یادداشتی با فرمتTXT،وLockFile اطلاعیه باج‌گیری خود را به صورت HTML Application – به اختصار HTA – ایجاد میکند. جالب اینجاست که اطلاعیه باج‌گیری HTA که توسط LockFile استفاده می‌شود بسیار شبیه یادداشتی است که توسط باج افزار LockBit 2.0 به‌کار برده می‌شود.
مهاجمان LockFile در اطلاعیه باج‌گیری خود از قربانیان می‌خواهند از طریق آدرس ایمیل زیر با آنها ارتباط برقرار کنند:
contact@contipauper.com
به نظر می‌رسد نام دامنه مورد استفاده یعنی contipauper.com اشاره‌ای تحقیرآمیز به گروه باج‌افزاری رقیب یعنی Conti است. ظاهراً این دامنه در 25 مرداد ایجاد شده است.
سپس ()EncryptDir_00007820 در خط شش فراخوانی می‌شود. قسمت اول تابع encrypt directory اهمیت چندانی ندارد.
قسمت دوم تابع رمزگذاری به صورت زیر است:
این باجافزار از ()FindFirstFile در خط 63 و ()FindNextFile در خط 129 برای تکرار از طریق دایرکتوری در param_1 استفاده میکند.
در قسمت اول (خطوط 91-66)، بررسی میکند که نام فایل شامل موارد زیر نباشد:
- lockfile.
- Windows\
- LOCKFILE
- NTUSER
سپس با درنظر گرفتن دو لیست زیر اجرا می‌شود. این دو لیست، انواع گوناگون پسوندهای شناخته شده اسنادی هستند که به آنها دست‌درازی نمی‌شود (سطرهای102-92).
نکته جالب توجه این است که این باجافزار به فایل‌های تصویری نظیر JPG نیز دست‌درازی نمی‌کند.
اگر پسوند فایل یک سند یافت شده در لیست‌های فوق نباشد، کد مذکور، نام فایل و مسیر را به هم متصل میکند (خط 103) و جهت رمزگذاری سند، ()EncryptFile_00007360 را فراخوانی میکند.
تابع ()EncryptFile_00007360 سند را از طریق نگاشت حافظه ورودی/خروجی رمزگذاری میکند.
سند ابتدا در خط 164 باز می‌شود و در خط 177، تابع ()CreateFileMapping سند را به حافظه نگاشت میکند. در خط 181، IVar17 به سند نگاشت شده در حافظه اشاره میکند.
کد با افزودن بخش رمزگشایی به انتهای سند در حافظه ادامه می‌یابد. در اینجا نمونه‌ای از یک سند آزمایشی که شامل 128 کاراکتر “a”ذ(0x61) است، مشاهده می‌شود.
پس از افزودن بخش رمزگشایی، اکنون سند نگاشت شده در حافظه به این شکل است:
در ادامه، سند به صورت 16 بایت 16 بایت، از طریق تابع ()EncryptBuffer_0002cbf4 در خط 271 رمزگذاری می‌شود.
د()EncryptBuffer_0002cbf4ئ16 بایت را در بافر دریافت شده lVar15 رمزگذاری میکند. در خط 268 روی lVar7 تنظیم شده که به سند نگاشت شده در حافظه اشاره میکند. جالب است که سپس 0x20 (30 بایت) به Ivar15 اضافه میکند و 16 بایت را رد میکند. این امر، رمزگذاری را متناوب میکند. نگاشت سند آزمایشی توسط حافظه پس از گذر اول در تصویر زیر نمایش داده شده است:
نگاشت سند آزمایشی توسط حافظه پس از گذر دوم در تصویر زیر نمایش داده شده است:
نگاشت سند آزمایشی توسط حافظه بعد از پردازش تمام بایت‌ها در زیر نشان داده شده است:
در ادامه تصویر متحرک زیر یک سند اصلی را با خروجی رمزگذاری شده توسط LockFile مقایسه میکند.
ویژگی قابل توجه این باجافزار این نیست که از رمزگذاری جزئی استفاده میکند. باج‌افزارهای دیگری نظیر LockBit 2.0 ،DarkSide و BlackMatter نیز تنها بخشی از اسنادی را که مورد حمله قرار میدهند رمزگذاری می‌کنند، صرفاً به دلیل اینکه مرحله رمزگذاری حمله را سریعتر انجام دهند. (آنها به ترتیب 4096 بایت اول، 512 کیلوبایت و 1 مگابایت را رمزگذاری می‌کنند).
چیزی که LockFile را نسبت به بقیه باج‌افزارها متمایز میکند این است که چند بلوک اول را رمزگذاری نمی‌کند. در عوض، LockFile به صورت یکی درمیان و 16 بایتی سند را رمزگذاری میکند. این بدان معناست که یک سند متنی، تا حدی قابل خواندن باقی می‌ماند.
استفاده از این رویکرد رمزگذاری متناوب مزیت جالبی دارد. این رویکرد، تحلیل‌های آماری را منحرف میکند و این امر موجب گمراهی برخی از فناوری‌های تشخیصی و دور زدن بعضی از راهکارهای امنیتی می‌شود.
روش رمزگذاری متناوب که در باجافزار LockFile استفاده می‌شود، روش chi-square (chi^2) را که توسط برخی از نرم‌افزارهای حفاظت در برابر باجافزار استفاده می‌شود، دور می‌زند. مقدار chi^2 در یک فایل متنی رمزگذاری نشده 481 کیلوبایتی (مثلاً یک کتاب)، 3850061 است. اگر سند توسط باجافزار Darkide رمزگذاری شود، مقدار chi^2 آن 334 می‌شودکه نشانه واضحی است از اینکه سند رمزگذاری شده است. اگر همان سند توسط باجافزار LockFile رمزگذاری شود، همچنان دارای مقدار بالا و قابل توجه 1789811 برای chi^2 است.
نمودار گرافیکی زیر (توزیع بایت/کاراکتر) سند متنی را که توسط دو باجافزار مختلف DarkSide و LockFile رمزگذاری شده است، نشان میدهد.
همانطور که در نمودارهای گرافیکی بالا مشاهده می‌کنید، نمایش گرافیکی سند متنی رمزگذاری شده توسط LockFile بسیار شبیه به نسخه اصلی آن است. این ترفند جهت تشخیص رمزگذاری در نرم‌افزارهای حفاظت از باج‌افزارها که بازرسی محتوا را با تحلیل آماری انجام میدهند، موفق خواهد بود. تا قبل از این، از رمزگذاری متناوب در حملات باج‌افزاری استفاده نشده بود.
پس از رمزگذاری، سند در خطوط 281-279 بسته می‌شود و فایل منتقل می‌شود (تغییر‌نام داده می‌شود):
رشته “s.lockfile%” در خطوط 298-284 رمزگشایی می‌شود و سپس در خط 300 به تابع ()sprint منتقل می‌شود تا پسوند “lockfile.” را به نام فایل اضافه کند.
در خط 301 نام فایل اصلی به نام فایل جدید تغییر میکند. جالب اینجاست که نام فایل جدید به حروف کوچک تغییر میکند و بعید است که رمزگشای LockFile بتواند نام فایل را به حالت اولیه بازگرداند، یعنی حروف بزرگ در نام فایل برای همیشه از بین می‌رود.
از آنجا که حمله از ()CreateFileMapping استفاده میکند، سند نگاشت و رمزگذاری شده در حافظه، توسط پروسه سیستمی Windows یعنی PID4، روی دیسک نوشته می‌شود. این را می‌توان از طریق ابزار Sysinternals Process Monitor مشاهده نمود. (توسط این ابزار می‌توان فعالیت نرم‌افزار‌ها و سرویس‌های درحال اجرا را مشاهده کرد و مدیریت کاملی بر روی آنها داشت. از ویژگی‌‌های بارز این نرم‌افزار می‌توان به نظارت آنی فایل‌های سیستمی، رجیستری و فعالیت‌های DLL اشاره کرد.)
در شکل زیر فیلتر Process Monitor حذف شده است تا فعالیت پروسه سیستم را مستثنی کند (PID 4):
با بکارگیری حافظه ورودی/خروجی نگاشت شده، باجافزار می‌تواند سریعتر به اسناد ذخیره شده دسترسی پیدا کند و به فرآیند Windows System اجازه میدهد عمل نوشتن را انجام دهد. با انجام عملیات WriteFile توسط فرایند Windows System، بایت‌های رمزگذاری شده واقعی توسط خود سیستم‌عامل، جدا از فرایند مخرب واقعی نوشته می‌شوند. در مثال بالا، این اتفاق شش ثانیه پس از رمزگذاری سند توسط باجافزار رخ میدهد، اما در سیستم‌های بزرگ این تاخیر می تواند تا چند دقیقه نیز باشد. این ترفند به تنهایی می‌تواند در برخی محصولات ضد باجافزار که مبتنی بر رفتار هستند نیز موثر باشد.
استفاده از نگاشت ورودی/خروجی حافظه در بین باج‌افزارها چندان رایج نیست، اگرچه توسط باج افزار Maze و باجافزار WastedLocker (کمتر دیده می‌شود) نیز استفاده می‌شود.
پس از رمزگذاری تمام اسناد روی دستگاه، باجافزار خود را با فرمان زیر حذف میکند:
cmd /c ping 127.0.0.1 -n 5 && del “C:\Users\Mark\Desktop\LockFile.exe” && exit
فرمان PING، پنج پیام ICMP را به localhost ارسال میکند و این فقط به عنوان یک sleep پنج ثانیه‌ای در نظر گرفته شده تا اجازه دهد فرایند باجافزار خودش را قبل از اجرای فرمان DEL که برای حذف باینری باجافزار صادر می‌شود، ببندد. این بدان معناست که پس از حمله باجافزار، هیچ باینری مربوط به بدافزار برای پاسخ‌دهندگان رویداد یا نرم‌افزارهای ضد ویروس جهت یافتن یا پاکسازی وجود ندارد.
همانند بسیاری از باج‌افزارهای هدفمند امروزی، باجافزار LockFile برای فعالیت‌های خود به تماس با سرورهای کنترل و فرماندهی (C2) در اینترنت نیازی ندارد. این بدان معناست که می‌تواند داده‌ها را روی ماشین‌هایی که دسترسی به اینترنت نیز ندارند رمزگذاری کند.
مشروح این گزارش در لینک زیر قابل مطالعه است:
