محققای Avast یک کمپین بدافزاری بنام GuptiMiner رو شناسایی کردن که از مکانیسم بروزرسانی آنتی ویروس eScan برای توزیع بدافزار استفاده میکنه.
محققا گفتن که این بدافزار یک تهدید پیچیده هستش و از یک زنجیره آلودگی همراه با چندین تکنیک جالب برای آلودگی استفاده میکنه، از جمله ارسال درخواستهای DNS به سرورهای DNS مهاجم ، اجرای تکنیک Sideloading ، استخراج پیلودها از تصاویر به ظاهر بی ضرر، امضای پیلودهاشون با یک مرجع صدور گواهی ROOT قابل اعتماد و … .
هدف اصلی GuptiMiner ، توزیع بکدور در شبکه های سازمانی بزرگ هستش. محققا در کل دو نوع از این بکدورهارو مشاهده کردن :
- نوع اول ، یک نمونه پیشرفته ساخته شده از PuTTY Link هستش که امکان اسکن SMB در شبکه محلی و حرکت جانبی در شبکه هایی با سیستم های آسیب پذیر ویندوز 7 و Windows Server 2008 رو میده.
- نوع دوم ماژولار هستش و امکان نصب ماژولهای بیشتر از طریق دستورات مهاجم رو میده. همچنین میتونه کلیدهای خصوصی دخیره شده و کیف های پول ارزهای دیجیتال رو در سیستمهای محلی اسکن و جمع آوری کنه.
محققا اعلام کردن که بدافزار ،استخراج کننده ارز دیجیتال، XMRig رو هم روی سیستم های آلوده مستقر میکنه که ایده ی مناسبی برای چنین بدافزاری نیست.
بازیگرای پشت GuptiMiner ، از یک آسیب پذیری در مکانیسم بروزرسانی آنتی ویروس هندی eScan ،که امکان حمله ی Man-In-The-Middle رو میده ،برای توزیع بدافزار استفاده میکنن. این آسیب پذیری بعد از گزارش محققا به eScan و CERT هند در 2023-07-31 اصلاح شده.
GuptiMiner یک بدافزار قدیمی هستش که احتمال میدن شاید به قبل از سال 2018 برگرده. محققا با شباهت هایی که بین کیلاگر گروه هکری منتسب به کره شمالی Kimsuky و این بدافزار پیدا کردن، احتمال میدن که شاید با این گروه هم ارتباط داشته باشه.
محققا در این گزارش به بررسی ویژگی های این بدافزار و روند تکامل اون پرداختن و یسری IoC برای شناسایی اون منتشر کردن.
زنجیره آلودگی :
شکل زیر روند زنجیره آلودگی رو نمایش میده. فقط اسم فایلها ، بسته به نسخه های GuptiMiner ، ممکنه متفاوت باشه.
فرایند آلودگی با درخواست بروزرسانی eScan شروع میشه که در اون از طریق یک MitM ، دانلود رهگیری شده و بسته بروزرسانی با بسته مخرب جایگزین میشه. در ادامه eScan ، این بسته مخرب رو آنپک و لوود میکنه که در نتیجه ی اون یک DLL لوود میشه (Sideloading). این DLL ادامه روند آلودگی رو از طریق شلکدها و لودرهای PE مختلف فراهم میکنه.
GuptiMiner در نهایت ماینر XMRig رو روی ماشین هدف اجرا میکنه و همچنین در صورتیکه با شبکه های سازمانی بزرگ روبرو بشه، یسری بکدور دیگه رو هم مستقر و اجرا میکنه.
تکامل و جدول زمانی:
GuptiMiner حداقل از سال 2018 فعال بوده و در این مدت توسعه دهندگان پشت اون، بهبودهای قابل توجه و ویژگی های جدیدی به اون اضافه کردن که در ادامه گزارش بهشون اشاره شده.
برای دسترسی به IoCها ، میتونید از این مخزن استفاده کنید.
دامنه ها در طول زمان :
بطور کلی ، GuptiMiner در طول عملیاتش از دامنه های مختلفی استفاده میکنه که محققا اونا رو در دسته بندی های زیر قرار دادن:
- Malicious DNS : بدافزار سرورهای DNS خودش رو میزبانی میکنه که ازشون برای ارائه ی آدرس نهایی C2 از طریق پاسخ های DNS TXT ، استفاده میکنه.
- Requested domains : دامنه هایی که موقع درخواست به Malicious DNS ازشون استفاده میشه.
- PNG download : سرورهای دانلود پیلود که بصورت فایلهای PNG ارائه میشن. این فایلها تصویر لوگوی T-Mobile هستن و شلکدها به انتهای اونا اضافه میشه.
- Config mining pool : بدافزار شامل دو پیکربندی مختلف برای استخر ماینیگ هستش. یکی بصورت مستقیم در پیکربندی XMRig قرار گرفته، که در این دسته بندی قرار دادن.
- Modified mining pool : بدافزار میتونه استخرهای از قبل تعریف شده رو هم دستکاری کنه که اونا رو در این دسته بندی قرار دادن.
- Final C&C : دامنه هایی که در آخرین مرحله از آلودگی استفاده میشن و قابلیت های بیشتری رو در سیستم آلوده فراهم میکنن.
- Other : دامنه هایی که در موارد دیگه ای مثلا در اسکریپتها استفاده میشن.
نکته ای که وجود داره اینه که ، چون بدافزار مستقیما به سرورهای DNS متصل میشه، پروتکل DNS بطور کلی از شبکه DNS مجزاست. بنابراین، هیچ سرور DNS قانونی هرگز ترافیک این بدافزار رو نخواهد دید. پروتکل DNS در اینجا بعنوان معادل عملکردی Telnet استفاده میشه. به همین دلیل، این تکنیک جعل DNS نیست، چون جعل بطور سنتی در شبکه DNS اتفاق می افته.
همچنین، این واقعیت که سرورهایی که GuptiMiner در دسته “Requested domain” استفاده میکنه، واقعاً وجود دارن، صرفاً یا یک تصادفه، یا بهتر بگیم، یک مخفی سازی شبکه ای، برای سردرگم کردن ابزارهای نظارت شبکه و تحلیلگران هستش.
همونطور که در شکل بالا مشاهده میکنید، راه اندازی سرورهای DNS برای عملکرد صحیح این بدافزار بسیار مهمه، برای همین بیشترین تغییرات و بازه های زمانی کوتاه رو برای گروه Malicious DNS ، مشاهده میکنید.
همچنین باتوجه به اینکه ، دامنه هایی که در گروه Requested domain هستن خیلی ضروری نیستن، توسعه دهندگان در بازه های زمانی طولانی مدت، ازشون استفاده کردن.
Mutex ها در طول زمان :
Mutexها به اطمینان از، اجرای صحیح جریان یک نرم افزار کمک میکنن و نویسندگان بدافزار نیز اغلب از این اشیاء برای همین منظور استفاده میکنن. از سال ۲۰۱۸، GuptiMiner چندین بار نام Mutexهای خودش رو تغییر داده. قابل توجه ترین تغییر از سال ۲۰۲۱ مشاهده شده، جایی که توسعه دهندگان Mutexها رو برای نشان دادن تاریخ کامپایل/پخش نسخه های جدید خودشون تغییر نام دادن.
در شکل بالا دو تا نکته مهم رو میشه مشاهده کرد:
- یکی اینکه MIVOD_6, SLDV15, SLDV13 و Global\Wed Jun 2 09:43:03 2021 در بیلدهای مختلف و در بازه های زمانی طولانی مدت استفاده شدن.
- معرفی PROCESS_ در اواخر سال گذشته انجام شده. در این بازه زمانی، توسعه دهندگان این mutex رو با یک رشته ی UTF-16 دوباره معرفی کردن
PDB ها در طول زمان :
با توجه به symbolهای دیباگینگ، توسعه دهندگان چندین مسیر PDB رو در باینریهاشون جا گذاشتن که اغلب ،شامل عباراتی مانند MainWork ، Projects و … هستش.
مرحله ی 0 – فرایند نصب و راه اندازی:
رهگیری بروزرسانی :
همه باید نرم افزارهاشون رو بروزرسانی کنن. این فرایند بروزرسانی یا بصورت دستی انجام میشه یعنی کاربر میره از سایت سازنده، نسخه بروز شده رو دانلود میکنه و نصب میکنه یا هم که بصورت خودکار ، خود برنامه فرایند بروزرسانی رو انجام میده. حالا به این فکر کنید که مهاجم، بتونه این مکانیسم بروزرسانی رو هک کنه. یعنی برنامه بجای اینکه برای اصلاح آسیب پذیری ها و … خودش بروز کنه، بره و یسری بدافزار رو دانلود و نصب و اجرا کنه.
کلا تحقیقات محققای Avast از اونجایی شروع شد که، متوجه شدن یسری از کاربراهاشون، یسری پاسخ های غیرمعمول برای یسری درخواست قانونی دریافت میکنن. مثلا مورد زیر :
1 |
http://update3[.]mwti[.]net/pub/update/updll3.dlz |
در شرایط نرمال ،این یک URL برای دانلود فایل updll3.dlz، که یک فایل فشرده قانونی حاوی بروزرسانی آنتی ویروس eScan هستش.
با این حال ، محققا متوجه رفتار مشکوک در برخی از مشتریاشون شدن که از این URL نشات میگرفت و تحقیقاتشون رو شروع کردن.
محققا متوجه شدن که بازیگرای پشت GuptiMiner ، با استفاده از حملات MitM ، بجای دانلود بروزرسانی، بدافزار روی سیستم قربانی نصب میکنن. اینکه چطوری این MitM رو انجام میدن، مشخص نیست اما معتقدن که احتمالا نوعی پیش آلودگی در دستگاه یا شبکه قربانی وجود داشته که امکان MitM رو میده. یعنی مهاجم ها یجورایی تونستن به سیستم یا شبکه دسترسی داشته باشن.
نکته جالب اینه که، هدف قرار دادن یک آنتی ویروس خیلی هوشمندانه بوده. چون کاربرایه خیلی کمی همزمان بیش از یک آنتی ویروس روی سیستمشون دارن و اصلا کل این آلودگی توسط کاربرایی که هم eScan و هم Avast رو سیستمشون بوده کشف شده. یعنی اگه Avast نبود، با توجه به آسیب پذیر بودن eScan و کنترلش توسط مهاجمین، شاید این آلودگی هرگز کشف نمیشد یا هم که به این زودی ها کشف نمی شد.
بروزرسانی بسته:
نمونه مورد بحث :
c3122448ae3b21ac2431d8fd523451ff25de7f6e399ff013d6fa6953a7998fa3(version.dll, 2018-04-19 09:47:41 UTC)
اولین نمونه GuptiMiner ، که محققا تونستن پیدا کنن، برمیگرده به 2018-04-19 که یک روز بعدش از هند در VirusTotal آپلود شده بود و بعدش از آلمان.
این فایل آپلود شده نام version.dll داشت و در مسیر C:\Program Files\eScan\VERSION.DLL ذخیره شده بود که نشون میده که کاربرای eScan رو هدف قرار داده و از بسته های بروزرسانی دانلود شده از آنتی ویروس میاد.
این نسخه اگرچه ویژگی های نسخه های جدیدتر رو نداره، اما روند نصب یکسانه :
- بروزرسانی eScan شروع میشه.
- بدلیل عدم استفاده و رمزگذاری HTTPS ، امکان حمله ی MitM وجود داره و بنابراین بسته مخرب جایگزین بسته قانونی میشه.
- بسته مخرب updll62.dlz، توسط آنتی ویروس دانلود و آنپک میشه.
- این بسته مخرب، شامل یک DLL مخرب ، که اغلب version.dll نامیده میشه، هستش که توسط آنتی ویروس لوود میشه. با توجه به اینکه تکنیک مورد استفاده برای لوود ، Sideloading هستش، DLL با همون امتیاز پروسس جاری و بعد از اجرای مجدد eScan اجرا میشه. معمولا بعد از ریستارت سیستم، اجرا میشه.
- اگه mutex در سیستم نباشه (که این mutex هم بسته به نسخه داره)، دنبال پروسس services.exe میگرده و مرحله ی بعدی رو به اون تزریق میکنه.
- پاکسازی انجام میشه و بسته مخرب بروزرسانی پاک میشه.
DLL مخرب حاوی توابعی هستش که در نسخه قانونی آنتی ویروس نیست که در شکل زیر مشاهده میکنید :
اسم توابع گویای عملکردشون است، اما برخیشون منحصر به فرد هستن. مثلا تابع X64Call یک Helper Function برای اجرای کدهای x64 در یک پروسس 32 بیتی در یک سیستم 64 بیتی رو فراهم میکنه. بدافزار به این تابع نیاز داره تا بتونه بسته به نسخه ی سیستم عامل و پروسس services.exe ، شلکدش رو تزریق کنه.
برای اینکه در عملکرد eScan اختلالی ایجاد نشه، نسخه ی مخرب version.dll باید عملکرد های DLL اصلی رو هم ارائه بده. برای این کار از ارسال مجدد توابع اکسپورت شده ی DLL اصلی استفاده میکنه. وقتی یک فراخوانی از توابع DLL اصلی شناسایی میشه، بدافزار تابع اصلی رو پیدا (resolves) و بعدش اونو فراخوانی میکنه.
تزریق شلکد به services.exe :
بعد از اینکه شلکد، به services.exe تزریق شد، این شلکد مانند لودر مرحله ی بعدی عمل میکنه. این کار از طریق خوندن یک فایل PE تعبیه شده که بصورت plaintext است، انجام میشه.
این فایل PE، بصورت استاندارد لوود میشه. البته شلکد هدر DOS رو از بین میبره و با فراخوانی entry point اونو اجرا میکنه. همچنین شلکد فایل PE تعبیه شده رو بطور کامل از محل اصلی حافظه پاک میکنه.
دستکاری خط فرمان :
در سراسر زنجیره آلودگی GuptiMiner، هر شلکدی که فایلهای PE رو لوود و تزریق میکنن، خط فرمان پروسس جاری رو هم دستکاری میکنن. این کار با تغییر خروجی با توابع GetCommandLineA یا GetCommandLineW انجام میشه که در نتیجه، خط فرمانی که در ابزارهایی مانند Task Manager نمایش داده میشه، تغییر میکنه.
محققا اومدن این عملکرد رو بررسی کردن و متوجه شدن که یا این تابع اونجوری که توسعه دهندگان میخواستن، کار نمیکنه یا محققا عملکرد اونو متوجه نمیشن. بصورت خلاصه خط فرمان اینجوری تغییر میکنه که همه چیز قبل از اولین –parameter حذف میشه و بعدش این پارامتر به اسم پروسس اضافه میشه.
مثلا اگه دستور زیر رو در نظر بگیریم :
1 |
notepad.exe param1 --XX param2 |
به صورت زیر تغییر میکنه:
1 |
notepad.exeXX param2 |
محققا موردی بصورت زیر هم ندیدن :
1 |
power --shell.exe param1 param2 |
که بصورت زیر تغییر کنه :
1 |
powershell.exe param1 param2 |
نکته قابل توجه اینه که محققا ، برخلاف انتظار از چنین بدافزاری، هیچ مخفی کاری در زمینه پارامترها (مانند نام کاربری و رمز عبور برای XMRig) مشاهده نکردن. با این حال، این قابلیت باعث مبهم سازی ظاهری خط فرمان میشه . علاقه مندان میتونن با این قابلیت اینجا کار کنن.
مجازی سازی کد:
نمونه مورد بحث:
7a1554fe1c504786402d97edecc10c3aa12bd6b7b7b101cfc7a009ae88dd99c6(version.dll, 2018-06-12 03:30:01)
محققا سال 2018 ، یک نمونه ای رو مشاهده کردن با mutex ONLY_ME_V3 که از کد مجازی سازی استفاده میکرده. این کد رو میشد در sectionای بنام v_lizer در فایل PE مشاهده کرد.
خوشبختانه مبهم سازی ضعیفه ، البته بستگی داره که شلکد و فایل PE تعبیه شده رو بصورت plaintext داشته باشید.
همچنین در نسخه های قبلی ،مرحله ی version.dll و لوود PE توسط یک mutex بنام ONLY_ME_Vx انجام میگرفت، اما در نسخه های جدید مرحله ی Sideloading از یک mutex دیگه بنام MTX_V101 استفاده میکنه.
مرحله ی 0.9 – بهبود مرحله ی نصب :
نمونه مورد بحث:
3515113e7127dc41fb34c447f35c143f1b33fd70913034742e44ee7a9dc5cc4c(2021-03-28 14:41:07 UTC)
با توجه به اینکه، مرحله ی نصب در طول زمان تغییرات و بهبودهای زیادی رو گرفته، محققا برای پوشش این موارد، اونارو در قالب مرحله ی 0.9 ارائه کردن.
بهبودهایی که اضافه کردن عبارتند از : استفاده از scheduled taskها ، رویدادهای WMI ، دو لوود متفوات برای مرحله بعدی (Stage 1 – PNG loader) ، خاموش کردن Windows Defender و نصب گواهی دستکاری شده در ویندوز.
همچنین در این مرحله، فایلهایی زیادی از طریق Sideloading لوود میشن. این فایلها، فایلهای تمییزی هستن و منحصرا با هدف Sideloading استفاده میشن.
DLLهای مخربی که از طریق Sideloading لوود میشن، دو تا لودر PNG هستن (مرحله ی 1) :
de48abe380bd84b5dc940743ad6727d0372f602a8871a4a0ae2a53b15e1b1739 *atiadlxx.dll
e0dd8af1b70f47374b0714e3b368e20dbcfa45c6fe8f4a2e72314f4cd3ef16ee *BrLogAPI.dll
رویدادهای WMI:
نمونه مورد بحث:
de48abe380bd84b5dc940743ad6727d0372f602a8871a4a0ae2a53b15e1b1739(atiadlxx.dll, 2021-03-28 14:30:11 UTC)
در این مرحله از رویدادهای WMI برای لوود کرد اولین لودر PNG استفاده میشه. این لودر در مسیر زیر قرار میگیره :
1 |
C:\PROGRAMDATA\AMD\CNext\atiadlxx.dll |
همچنین یسری فایل تمیز ، با هدف Sideloading ، در مسیرهای زیر (ممکنه در هر دو باشه)، قرار میگیره :
1 2 3 4 5 |
C:\ProgramData\AMD\CNext\slsnotif.exe C:\ProgramData\AMD\CNext\msvcr120.dll or C:\Program Files (x86)\AMD\CNext\CCCSlim\slsnotify.exe C:\Program Files (x86)\AMD\CNext\CCCSlim\msvcr120.dll |
سپس فایل تمیز slsnotify.exe طوری از طریق رویداد WMI رجیستر میشه که در صورت برآورده شدن شرایط زیر اجرا بشه:
به عبارت دیگه، Sideloading در یک روز کاری، در ماههای ژانویه، جولای یا نوامبر انجام میشه. اعداد نمایش داده شده توسط %d مقادیر انتخاب شده بصورت تصادفی هستن. دو احتمال برای ساعت وجود داره، دقیقا دو ساعت از هم فاصله دارن و در محدوده ۱۱ تا ۱۶ یا ۱۳ تا ۱۸ (شامل این اعداد) هستن. این شرط بندی، بر تداوم فعالیتهای GuptiMiner تأکید میکنه.
Scheduled Taskها :
نمونه مورد بحث:
e0dd8af1b70f47374b0714e3b368e20dbcfa45c6fe8f4a2e72314f4cd3ef16ee(BrLogAPI.dll, 2021-03-28 14:10:27 UTC)
همانند رویدادهای WMI، بدافزار یک باینری تمیز رو برای Sideloading در این مسیر قرار میده :
1 |
C:\ProgramData\Brother\Brmfl14c\BrRemPnP.exe |
بعدش لودر مخرب PNG در یکی از این مکانها (یا هر دو) قرار میگیره:
1 2 |
C:\Program Files (x86)\Brother\Brmfl14c\BrLogAPI.dll C:\Program Files\Brother\Brmfl14c\BrLogAPI.dll |
یک تسک با ویژگی های زیر، از طریق Task Scheduler ایجاد میشه:
- با نام و در مکان زیر :
1 |
C:\Windows\System32\Tasks\Microsoft\Windows\Brother\Brmfl14c |
- اجرایی زیر رو اجرا میکنه:
1 |
C:\ProgramData\Brother\Brmfl14c\BrRemPnP.exe |
- محل اجرا: داخل فولدریه که حاوی DLLای است که باید به صورت جانبی بارگذاری بشه، مثلا:
1 |
C:\Program Files (x86)\Brother\Brmfl14c\ |
- زمان اجرا: در هر راهاندازی سیستم (TASK_TRIGGER_BOOT) با سطح دسترسی SYSTEM
استقرار در هنگام خاموش شدن :
نمونه مورد بحث:
3515113e7127dc41fb34c447f35c143f1b33fd70913034742e44ee7a9dc5cc4c(2021-03-28 14:41:07 UTC)
حالا بیایید ببینیم چطوری این فایلها، تمیز و مخرب، مستقر میشن. یکی از ترفندهایی که بدافزار انجام میده اینه که ، پیلود نهایی رو موقع خاموش شدن سیستم مستقر میکنه. در این زمان برنامه ها هم خاتمه داده میشن و بنابراین احتمالا از کاربر محافظت نمیشه و در نتیجه استقرار پیلود میتونه بی خطر باشه.
با توجه به کد بالا، اگه مقدار SM_SHUTTINGDOWN غیر صفر باشه، یعنی جلسه فعلی در حال خاتمه هستش و اگه همه ی فایلهای تمیز با موفقیت مستقر شده باشن، پیلود DLL نهایی هم مستقر میشه.
اگه به کد بالا دقت کنید، بدافزار با استفاده از تابعی به نام disable_defender اقدام به غیرفعال کردن Windows Defender میکنه. این کار از طریق دستکاری رجیسترها انجام میگیره. تنها در صورتی که Windows Defender غیر فعال باشه، بدافزار اقدامات مخربش رو انجام میده.
اضافه کردن گواهی به ویندوز :
اغلب اوقات بدافزار GuptiMiner از باینری های self-signed برای اقدامات مخرب استفاده میکنه. اما این بار توسعه دهندگان یک قدم فراتر رفتن. در این نمونه، هر دو DLL لودر PNG از طریق یک مرجع صدور گواهی root سفارشی امضاء شدن. یعنی امضاء ذاتا غیرقابل اعتماده، چون مرجع صدور گواهی مهاجمین توسط فرآیندهای تأیید رایج در ویندوز قابل اعتماد نیست.
با این حال بدافزار موقع نصب ، یک گواهی root به Windows certificate store اضافه میکنه و این مرجع صدور گواهی رو معتبر میکنه. بنابراین وقتی این چنین فایل امضاء شده ای اجرا میشه، امضای اون قابل اعتماد در نظر گرفته میشه. این کار توسط توابع CertCreateCertificateContext, CertOpenStore, CertAddCertificateContextToStore انجام میگیره.
گواهی بصورت plaintext در فایل باینری بدافزار موجود هستش .
محققا در طول تحقیقات خودشون، با سه صادر کننده گواهی روبرو شدن که بدافزار GuptiMiner در طول فعالیتش ازشون استفاده کرده :
GTE Class 3 Certificate Authority
VeriSign Class 3 Code Signing 2010
DigiCert Assured ID Code Signing CA
توجه داشته باشید که این نامها ساختگی هستن و هر شباهتی به مراجع صدور گواهی معتبر، تصادفی تلقی میشه.
ذخیره پیلود در رجیستری :
نمونه مورد بحث:
8e96d15864ec0cc6d3976d87e9e76e6eeccc23c551b22dcfacb60232773ec049(upgradeshow.dll, 2023-11-23 16:41:34 UTC)
در مراحل بعدی توسعه، بازیگران پشت بدافزار، برای بهتر کردن روند پرسیستشون ، از کلیدهای رجیستری هم استفاده کردن. همچنین پیلودها از طریق XOR و یک کلید ثابت، رمزگذاری شدن. این تضمین میکنه که پیلودها با چشم بدون مسلح ، بی معنی به نظر برسن.
مسیرهای رجیستری که محققا کشف کردن، موارد زیر هستش :
1 2 3 4 |
SYSTEM\CurrentControlSet\Control\Nls\Sorting\Ids\en-US SYSTEM\CurrentControlSet\Control\PnP\Pci\CardList SYSTEM\CurrentControlSet\Control\Wdf\DMCF SYSTEM\CurrentControlSet\Control\StorVSP\Parsers |
مرحله 1 – لودر PNG :
نمونه مورد بحث:
ff884d4c01fccf08a916f1e7168080a2d740a62a774f18e64f377d23923b0297(2018-04-19 09:45:25 UTC)
وقتی entry point فایل PE توسط شلکد در مرحله ی 0 اجرا شد، بدافزار یک scheduled task ایجاد میکنه، تا آلودگی اولیه رو از طریق حذف updll62.dlz و version.dll از سیستم قربانی پاک کنه.
همچنین، این فایل PE به عنوان dropper برای مراحل بعدی عمل میکنه و با برقراری ارتباط با سرور مخرب DNS مهاجم، مراحل بعدی رو دریافت میکنه. این کار با ارسال یک درخواست DNS به سرور DNS مهاجم و دریافت رکورد TXT در پاسخ انجام میشه. پاسخ TXT حاوی یک دامنه URL رمزگذاری شده برای سرور C2 واقعیه که، باید برای دریافت یک پیلود دیگه درخواست بشه.
این پیلود یک فایل PNG معتبره (لوگوی T-Mobile) که در انتهای اون یک شلکد هم ضمیمه شده. شلکد بعدش توسط بدافزار در یک Thread جداگانه اجرا میشه و بعنوان مرحله بعدی، قابلیت های مخرب بیشتری رو برای بدافزار فراهم میکنه.
توجه کنید که خود سرور DNS مخرب هستش و دامنه درخواستی اصلا مهم نیست. بصورت انتزاعی میشه این دامنه رو بعنوان یک رمزعبور در نظر گرفت که به سرور ارسال میشه و تصمیم گیری میشه که آیا سرور DNS ، باید پاسخ TXT رو ارسال کنه یا نه.
همونطور که قبلا اشاره شد، یسری دامنه در قالب Requested domains در این فرایند مورد استفاده قرار میگیرن. مثلا در نسخه ای که اینجا آنالیز شده، موارد زیر بودن :
1 2 |
ext.peepzo[.]com crl.peepzo[.]com |
و آدرس سرور DNS مخرب در این نمونه :
1 |
ns1.peepzo[.]com |
شکل زیر یک نمونه پاسخ گرفته شده از DNS TXT در وایرشارک رو نشون میده. نکته ای که محققا بهش اشاره کردن اینه که ، Transaction ID = 0x034b در طول سالها عملیات این بدافزار بدون تغییر باقی مونده. جالب بودنش هم از این جهته که فایروالها یا EDRها میتونن از این طریق ، بدافزار رو شناسایی کنن.
درخواستهایی هم که بدافزار ارسال میکنه در فواصل زمانی تصادفی رخ میده. درخواست اولیه برای رکورد DNS TXT در 20 دقیقه اول بعد از اجرای لودر PNG انجام میگیره. درخواستهای بعدی که برای بروزرسانی بدافزار انجام میگیره، تا 69 ساعت صبر میکنه.
این مکانیزم بروزرسانی با ایجاد mutexهای جداگانه، با شماره نسخه شلکد که با دو بایت اول پاسخ رمزگشایی شده ی TXT DNS مشخص میشه (جزئیات فرایند رمزگشایی در ادامه توضیح داده شده) نمایش داده میشه. این کار اطمینان میده که هیچ شلکدی با نسخه ی یکسان، دو بار روی سیستم اجرا نمیشه.
رمزگشایی رکورد DNS TXT :
بعد از دریافت رکورد DNS TXT ، بدافزار محتوای اونو با base64 دیکد میکنه و بعدش اونو با ترکیبی از MD5 که بعنوان Key derivation functions (KDF) (کلید رو از منابع دیگه اسخراج میکنه) و الگوریتم RC2 ، رمزگشایی میکنه.
البته در نسخه های بعدی ، توسعه دهندگان بدافزار ، فرایند رمزگشایی رو با استفاده از checksum ها و کلیدهای رمزگشایی اضافی، بهبود دادن.
برای KDF و فرایند رمزگشایی ، از توابع Windows CryptoAPI استفاده کردن که در شکل زیر مشاهده میکنید.
در شکل بالا تابع CryptHashData داریم که در مستندات مایکروسافت، بصورت زیر تعریف میشه:
1 2 3 4 5 6 |
BOOL CryptHashData( [in] HCRYPTHASH hHash, [in] const BYTE *pbData, [in] DWORD dwDataLen, [in] DWORD dwFlags ); |
آرگومان دوم این تابع، یک اشاره گر به آرایه ای از بایتها به اندازه ی dwDataLen هستش. اما، بدافزار از رشته “POVO@1” در فرمت یونیکد (UTF-16) استفاده کرده که توسط آرایه ای از بایت های *pbData ارائه میشه.
بنابراین، شش بایت اول از این آرایه فقط شامل db ‘P’، 0، ‘O’، 0، ‘V’، 0 هستش که بطور مؤثر کلید رو نصف و اونو با صفر پر میکنه. اگرچه توسعه دهندگان بدافزار کلید رمزگشایی رو در طول سال ها تغییر دادن، اما هرگز این نقض رو برطرف نکردن و این مشکل همچنان در آخرین نسخه GuptiMiner وجود داره.
تجزیه رکورد DNS TXT :
در این نمونه، موقع دسترسی به سرور مخرب DNS مهاجمین ، ns.srnmicro[.]net ، و درخواست دامنه ی spf.microsoft[.]com ، سرور رکورد زیر رو برمیگردونه :
1 |
VUBw2mOgagCILdD3qWwVMQFPUd0dPHO3MS/CwpL2bVESh9OnF/Pgs6mHPLktvph2 |
بعد از رمزگشایی کامل تبدیل به مقدار زیر میشه :
نتایج شامل چندین فیلد هستش که میشه بصورت زیر تفسیرشون کرد :
Name | Value |
Version 1 | 1 |
Version 2 | 5 |
Key size | \r (= 0xD ) |
Key | Microsoft.com |
C&C URL | http://www.deanmiller[.]net/m/ |
Checksum | \xde |
دو بایت اول ، یعنی Version 1 و Version 2 مشخص کننده ، نسخه ی شلکد PNG هستش. مشخص نیست چرا این دو تا نسخه وجود داره، چون Version 2 در واقع هرگز استفاده نمیشه. فقط Version 1 استفاده میشه اونم برای اینکه مشخص بشه شلکد PNG دانلود و لوود شده یا نه. میشه این نسخه هارو بعنوان major و minor هم در نظر گرفت که فقط نسخه ی major در عمل مورد استفاده قرار میگیره.
بایت سوم، اندازه کلید رو نشون میده که چند بایت بعد از اون باید خونده بشه تا کلید کامل بشه. علاوه بر این، بدلیل اینکه اندازه کلید مشخصه و URL مستقیما بعد از اون قرار میگیره، هیچ جداکننده اضافی بین کلید و URL مورد نیاز نیست.
در آخر، دو بایت checksum داریم که میتونه از طریق محاسبه ی همه ی بایتها، رکورد دریافتی رو تایید کنه. ( با محاسبه ی باقی مانده تقسیم بر 0xFF=255)
بعد از اینکه رکورد DNS TXT دیکد و رمزگشایی شد، بدافزار مرحله ی بعدی رو از URL ارائه شده در قالب فایل PNG، دانلود میکنه. این کار با تابع WinINet انجام میده. User-Agent هم با معماری پروسس جاری (32 یا 64 بیتی) پر میشه.
سرور C2 از این اطلاعات User-Agent ، در موارد زیر استفاده میکنه :
- مرحله بعدی که یک شلکد هستش رو با معماری درستی ارائه میده.
- هر درخواست HTTP که حاوی این اطلاعات نیست رو بعنوان یک مکانیزم حفاظتی ، فیلتر میکنه.
تجزیه ی فایل PNG :
فایل دانلود شده، یک فایل معتبر PNG هستش که یک شلکد به انتهای اون اضافه شده. این فایل لوگوی T-Mobile و دقیقا 805 بایت سایزشه. این بایتها توسط بدافزار نادیده گرفته میشن و باقی فایل، از آفست 0x325 به بعد، با استفاده از الگوریتم RC2 و کلیدی که در پاسخ TXT (استخراجشده با استفاده از MD5) ارائه شده، رمزگشایی میشن. دلیل استفاده از تصویر اینه که ارتباط شبکه رو بیشتر مخفی میکنه، چون پیلود شبیه یک تصویر قانونی به نظر میرسه و احتمالاً شلکد اضافه شده به اون، نادیده گرفته میشه.
پس از لوود شلکد از موقعیت 0x325، بدافزار برای خارج سازی مراحل بعدی، با استفاده از Gzip، اقدام به لوود یک لودر PE دیگه از حافظه میکنه.
IP Address Masking :
نمونه ی مورد بحث:
294b73d38b89ce66cfdefa04b1678edf1b74a9b7f50343d9036a5d549ade509a(2023-11-09 14:19:45 UTC)
در اواخر سال 2023، توسعه دهندگان بدافزار، تصمیم گرفتن رویکرد چند ساله اشون در خصوص توزیع بدافزار از طریق رکوردهای DNS TXT رو کنار بزارن و به جاش از IP address masking استفاده کنن.
این رویکرد جدید شامل چندین مرحله بود :
- با استفاده از تابع gethostbyname ، بدافزار آدرس IP یک سرور هاردکد شده که توسط مهاجم ثبت شده رو بدست میاره.
- برای اون سرور، دو تا IP برگردونده میشه. اولی در حقیقت یک IP Address Masking و دومی نشون دهنده یک نسخه پیلود قابل دسترسه و با 23.195 شروع میشه.
- اگه نسخه جدیدتر از نسخه فعلی باشه، آدرس IP ماسک شده رمزگشایی شده (de-masked) و به یک آدرس IP واقعی C2 تبدیل میشه.
- از آدرس IP واقعی سرور C&C بهمراه یک رشته ثابت هاردکد شده (که در مسیر URL استفاده میشه) برای دانلود فایل PNG حاوی شلکد استفاده میشه.
فرایند رمزگشایی (de-masked) با XOR کردن هر اکتت IP به ترتیب با 0xA, 0xB, 0xC, 0xD انجام میگیره. سپس نتیجه به دست اومده و یک رشته ثابت هاردکد شده به مسیر URL اضافه میشه.
بعنوان مثال، یکی از سرورهایی که محققا مشاهده کردن، www.elimpacific[.]net بوده، که مقدار برگشتیش بصورت زیر هستش:
آدرس 1[.]23.195.101 مشخص کننده نسخه هستش، اگه نسخه جدیدتری وجود داشته باشه، با دانلود فایل PNG همراه با شلکد، عمل بروزرسانی انجام میگیره.
این بروزرسانی از طریق دانلود فایل PNG با درخواست از سرور واقعی C2 انجام میگیره. آدرس این سرور C2 هم از طریق رمزگشایی آدرس 38[.]179.38.204 محاسبه میشه :
در ادامه این آدرس IP محاسبه شده،یعنی 43[.]185.45.192 ، همراه با مقدار هاردکد شده ی elimp ارسال میشه. در حقیقت از این مقدار ثابت elimp، بعنوان پسورد استفاده میکنه :
1 |
185.45.192[.]43/elimp/ |
بعد از دانلود PNG، بقیه مراحل مثله قبل هستش.
محققا دو سرور رو در این خصوص شناسایی کردن :
Queried server | URL path constant |
www.elimpacific[.]net |
elimp |
www.espcomp[.]net |
OpenSans |
ترفندهای Anti-VM و Anti-debug :
نمونه مورد بحث:
294b73d38b89ce66cfdefa04b1678edf1b74a9b7f50343d9036a5d549ade509a(2023-11-09 14:19:45 UTC)
محققا همچنین بهبودهایی در روشهای استفاده از Anti-VM و Anti-debugging مشاهده کردن. برای این کار از روشهایی مانند بررسی نام درایورهای دیسک شناخته شده، کلیدهای رجیستری و پروسس های در حال اجرا ، استفاده میکنه.
GuptiMiner برای بررسی درایورهای دیسک ، موارد زیر بررسی میکنه :
1 2 3 4 5 6 |
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\Disk\Enum: vmware qemu vbox virtualhd |
بطور خاص، بدافزار کلید رجیستری زیر رو برای شناسایی Cylance AV انجام میده :
1 |
HKEY_LOCAL_MACHINE\SOFTWARE\Cylance |
همچنین بعنوان یه ترفند Anti-VM دیگه، بررسی میکنه که آیا سیستم دارای بیش از 4 گیگ رم و 4 هسته CPU هست یا نه.
همچنین پروسس های زیرو رو با پیشوندهای زیر بررسی میکنه :
Process name prefix | Tool name |
wireshar |
Wireshark |
windbg. |
WinDbg |
tcpview |
TCPView |
360 |
360 Total Security |
hips |
Huorong Internet Security (hipsdaemon.exe ) |
proce |
Process Explorer |
procm |
Process Monitor |
ollydbg |
OllyDbg |
ذخیره تصاویر در رجیستری:
نمونه مورد بحث:
6305d66aac77098107e3aa6d85af1c2e3fc2bb1f639e4a9da619c8409104c414(2023-02-22 14:03:04 UTC)
همانند ذخیره پیلودها در رجیستری، تصاویر PNG رو هم در رجیستری ذخیره میکنه. با این تفاوت که ، تصاویر مثله پیلودها با XOR رمز نمیشن، چون همونطور که قبلا گفته شد با RC2 رمز شده بودن.
مسیرهای رجیستری که محققا برای این منظور کشف کردن موارد زیر:
1 2 3 4 5 6 7 |
SYSTEM\CurrentControlSet\Control\Arbiters\Class SYSTEM\CurrentControlSet\Control\CMF\Class SYSTEM\CurrentControlSet\Control\CMF\CORE SYSTEM\CurrentControlSet\Control\CMF\DEF SYSTEM\CurrentControlSet\Control\CMF\Els SYSTEM\CurrentControlSet\Control\CMF\ASN SYSTEM\CurrentControlSet\Control\MSDTC\BSR |
مرحله ی دوم – لودر Gzip :
نمونه مورد بحث:
357009a70daacfc3379560286a134b89e1874ab930d84edb2d3ba418f7ad6a0b(2019-04-02 07:30:21 UTC)
این مرحله کوتاهترین مرحله در این بدافزار هستش. این لودر از شلکد استخراج و اجرا شده از فایل PNG اجرا میشه. لودر Gzip یک فایل PE ساده است که وظیفه اش خارج کردن یک شلکد دیگه با استفاده از Gzip و اجرای اون در یک Thread دیگه است.
این Thread همچنین مرحله سوم که محققا اسمش رو Puppeteer گذاشتن رو لوود میکنه که در حقیقت عملکرد اصلی بدافزار یعنی استقرار استخراج کننده ارزهای دیجیتال و در صورت نیاز استقرار بکدورهای دیگه در سیستم، رو تنظیم میکنه.
در طول عملیاتی که این بدافزار انجام داده، لودر Gzip در نسخه های بعدی تغییری نداشته.
مرحله سوم : Puppeteer
نمونه مورد بحث:
364984e8d62eb42fd880755a296bd4a93cc071b9705c1f1b43e4c19dd84adc65(2019-03-15 10:07:36 UTC)
این مرحله طولانی ترین مرحله ی این بدافزار هستش. این مرحله تمام اجزای GuptiMiner را در سراسر سیستم آلوده دستکاری میکنه، برای همینه محققا اسم Puppeteer (عروسک گردان) رو براش انتخاب کردن. Puppeteer اقدامات بعدی رو سازماندهی میکنه و دو مولفه ی اصلی بدافزار یعنی استخراج کننده ارز دیجیتال XMRig و دو نوع بکدور که دستگاه های موجود در شبکه های شرکتی بزرگ رو هدف قرار میده، رو مستقر میکنه. Puppeteer همچنین ویژگی های دیگه ای رو به کل عملیات GuptiMiner اضافه میکنه.
این مرحله همچنین از یکی از mutex های Global\SLDV که در جدول زمانی Mutex توضیح داده شده استفاده میکنه. برای مثال، این نمونه خاص از SLDV01 به عنوان mutex خودش استفاده میکنه.
راه اندازی Puppeteer :
Puppeteer چندین مرحله رو برای راه اندازی مناسب انجام میده. اولا، یک Power Scheme جدید در ویندوز اضافه میکنه تا رایانه به Sleep نره. اگر CPU فقط یک هسته داشته باشه (Anti-VM) یا mutex از قبل وجود داشته باشه، بدافزار با رفتن به Infinite Sleep از کار می افته.
در مرحله ی بعد ، بدافزار پروسس هایی با نام های msiexec.exe, cmstp.exe, credwiz.exe رو خاتمه میده. بعدش یک پروسس جدید بنام credwiz.exe ایجاد میکنه و با یک Thread مجزا ، XMRig به داخلش تزریق میکنه. همچنین Windows Defender رو از طریق غیرفعال کردن Service Start Status ، غیرفعال میکنه.
برای پرسیست، Puppeteer رویکرد جالبی داره. ابتدا یک Scheduled Task با ویژگی های زیر ایجاد میکنه :
- فایل قانونی rundll32.exe رو در مسیر زیر کپی و تغییر نام میده و اونو از Scheduled Task اجرا میکنه.
1 |
C:\ProgramData\Microsoft\Crypto\Escan\dss.exe |
- DLL مخرب در مسیر زیر قرار داره و از طریق dss.exe اجرا میشه. (exported function ValidateFile)
1 |
C:\ProgramData\Microsoft\Crypto\Escan\updll3.dll3 |
- تسک ایجاد شده با هر بوت (TASK_TRIGGER_BOOT) و اولویت TASK_RUNLEVEL_HIGHEST اجرا میشه.
- تسک با نام و در مسیر زیر قرار میگیره :
1 |
C:\Windows\system32\tasks\Microsoft\windows\autochk\ESUpgrade |
با این کار بدافزار محتوای updll3.dll3 رو در مموری کپی میکنه و فایل اصلی رو از رو دیسک پاک میکنه. Puppeteer سپس منتظر خاموش شدن سیستم میمونه. این کار مشابه Stage 0.9، با بررسی مقدار عددی SM_SHUTTINGDOWN که در صورت خاموش شدن، غیر صفر میشه، انجام میده. این مقدار هر 100 میلی ثانیه بررسی میشه. زمانی که خاموش شدن سیستم آغاز میشه، بدافزار فایل updll3.dll3 رو دوباره روی دیسک قرار میده.
قرار دادن دوباره DLL مخرب، درست قبل از راه اندازی مجدد سیستم، واقعا یک حقه زیرکانه هستش، اما همچنین میتونه پیامدهای منفی داشته باشه. اگه دستگاه قربانی دچار خرابی، قطع برق یا هر گونه خاموشی غیرمنتظره بشه، فایل از حافظه بازیابی نمیشه و Puppeteer از این نقطه به بعد از کار می افته. شاید به همین دلیله که نویسندگان این ترفند رو در نسخه های بعدی حذف کردن و بجای ظرافت، ثبات بدافزار رو در نظر گرفتن.
لوود مکرر updll3.dll3 ، همانطور که در کد بالا مشاهده میکنید، در حقیقت فرایند بروزرسانی Puppeteer هستش. DLL درنهایت شلکد PNG رو از سرور C2 درخواست میکنه و اگه نسخه جدید باشه، فرایند بروز میشه.
استقرار XMRig :
در طول راه اندازی، Puppeteer یک Thread جدید برای تزریق XMRig در پروسس credwiz.exe ایجاد میکنه. اما قبل از تزریق، چندین مرحله آماده سازی انجام میگیره.
تنظیمات XMRig بصورت مستقیم درون باینری XMRig (تنظیمات استاندارد JSON) که در باینری Puppeteer ذخیره شده، وجود داره. با این حال، این تنظیمات رو میشه بصورت داینامیک و در لحظه به مقادیر مختلفی تغییر داد. در مثال زیر، تخصیص داینامیک Threadهای استخراج رو بسته به قدرت سخت افزار سیستم آلوده مشاهده میکنید.
برای تزریق، بدافزار یک پروسس Suspended از credwiz.exe ایجاد میکنه، اگه این مرحله موفقیت آمیز باشه، استخراج کننده ارز دیجیتال از طریق WriteProcessMemory و CreateRemoteThread تزریق و اجرا میشه.
Puppeteer بطور مداوم هر 5 ثانیه یکبار، پروسس های در حال اجرا رو بررسی میکنه. اگه با هر یک از ابزارهای نظارتی زیر مواجه بشه، بدافزار هرگونه استخراج رو با خاتمه پروسس credwiz.exe و همچنین یک Sleep موقت، که تزریق مجدد رو به 5 ساعت دیگه موکول میکنه، متوقف میکنه.
taskmgr.exe
autoruns.exe
wireshark.exe
wireshark-gtk.exe
tcpview.exe
همچنین بدافزار باید مکان updll3.dll3 رو پیدا کنه، اونو در مموری ذخیره کنه، از روی دیسک حذفش کنه و موقع راه اندازی مجدد سیستم، اونو مجدد در دیسک بریزه. برای رسیدن به این هدف، دو رویکرد رو انجام میده :
- خوندن مکان فولدر eScan از مسیر رجیستری زیر :
1 |
HKEY_LOCAL_MACHINE\SOFTWARE\AVC3 |
- اگه نام یکی از پروسس های بررسی شده ، download.exe باشه، که یک باینری قانونی برای eScan هستش، مکان فایل رو برای بدست آوردن فولدر برنامه ، استخراج میکنه. خروجی میتونه بصورت زیر باشه:
1 |
\Device\HarddiskVolume1\Program Files (x86)\eScan\download.exe |
بررسی download.exe، بعنوان جایگزینی برای پیدا کردن فولدر نصب eScan استفاده میشه، و بنظر میاد از مثال مندرج در MSDN استخراج شده.
در نهایت، Puppeteer بطور مداوم مصرف CPU رو در سیستم نظارت میکنه و تخصیص هسته رو بگونه ای تغییر میده که منابع زیادی مصرف نشه و زیر رادار بمونه.
راه اندازی بکدور :
نمونه مورد بحث:
4dfd082eee771b7801b2ddcea9680457f76d4888c64bb0b45d4ea616f0a47f21(2019-06-29 03:38:24 UTC)
بکدور توسط مرحله قبل، یعنی Puppeteer، راه اندازی میشه. بدافزار ابتدا بررسی میکنه که آیا دستگاه روی ویندوز سرور کار میکنه یا نه. این کار رو با بررسی کلید رجیستری DNS Server انجام میده (سرویس DNS Server معمولا روی نسخه های ویندوز سرور اجرا میشه):
1 |
SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS Server |
بعدش بدافزار، دستور زیر رو برای بررسی و دریافت تعداد کامپیوترهای عضو یک دامنه اجرا میکنه :
1 |
net group “domain computers” /domain |
خروجی دستور net group معمولا از 25 کاراکتر به ازای هر کامپیوتر عضو دامنه بعلاوه یک خط جدید (CR+LF) به ازای هر سه کامپیوتر ، استفاده میشه. شکل زیر یک نمونه از این خروجی رو نمایش میده :
در این نسخه از راه اندازی بکدور، Puppeteer بررسی میکنه که آیا تعداد بایتهای برگشتی بیش از 100 بایت است یا نه. اگه اینجوری باشه، Puppeteer ، فرض میکنه که در یک network shared با حداقل 5 کامپیوتر هستش و پیلود دیگه ای رو از C2 هاردکد شده (https://m.airequipment[.]net/gpse/) دانلود و اونو با دستور پاورشل اجرا میکنه.
در نسخه های بعدی GuptiMiner، تعداد بایتهای برگشتی افزایش یافته بود و تنها شبکه هایی که بیش از 7000 کامپیوتر دارن رو آلوده میکرد.
اگه بررسی موارد بالا درست باشه، Puppeteer از دستور پاورشل برای دانلود و اجرای پیلود استفاده میکنه. اجرا هم در پروسس جاری اجرا میشه و هم در پروسس explorer.exe تزریق میشه.
همچنین صرفنظر از اینکه کامپیوتر در شبکه ای با اندازه مشخصه یا نه، بدافزار یه پیلود دیگه از dl.sneakerhost[.]com/u دانلود میکنه. این پیلود یک فایل PNG دیگه با یک شلکد داخلشه و از همون مکانیسیمی که در مرحله یک توضیح داد شد، 0x325 بایت به بعد، استفاده میکنه. محققا اعلام کردن که بدلیل حذف دامنه ، نتونستن پیلود رو بدست بیارن و در نتیجه نمیدونن که دقیقا چه کاری انجام میده.
فرایند راه اندازی Puppeteer ، در طول توسعه اش، چندین بار تغییر و بهبود یافته که در بخش های بعدی به نکات مهم اش اشاره شده.
نسخه های بعدی Puppeteer :
در نسخه های بعدی، مهاجمین به الگوی mutex مبتنی بر تاریخ و زمان (همانطور که در بخش “Mutex ها در طول زمان” اشاره شد) روی آوردن و همچنین نظارت بر پروسس های بیشتری از ابزارهای Sysinternals مانند Process Explorer و Process Monitor و همچنین ابزارهایی مانند OllyDbg، WinDbg و TeamViewer رو اضافه کردن.
پیکربندی استخر :
نمونه مورد بحث:
487624b44b43dacb45fd93d03e25c9f6d919eaa6f01e365bb71897a385919ddd(2023-11-21 18:05:43 UTC)
همچنین، توسعه دهندگان GuptiMiner شروع به تغییر آدرس های استخر در تنظیمات XMRig با یک رویکرد جدید کردن. اونا با توجه به میزان حافظه رم موجود در سیستم آلوده، شروع به استفاده از زیر دامنه هایی با “r” و “m” کردن:
- در صورتی که حداقل 3 گیگابایت رم در دسترس باشه، بدافزار از موارد زیر استفاده میکنه:
- m.domain.tld با حالت خودکار (auto mode) و صفحات حجیم فعال (enabled huge pages)
- اگر رم در دسترس کمتر از 3 گیگابایت باشه، از موارد زیر استفاده میکنه:
- r.domain.tld با حالت سبک (light mode) و صفحات حجیم غیرفعال (disabled huge pages)
برای اینکه همه چیز ساده نباشه، توسعه دهندگان بعداً در برخی نسخه ها شروع به استفاده از “p” به عنوان زیر دامنه کردن، بدون اینکه دلیل خاصی برای این نامگذاری وجود داشته باشه (احتمالاً فقط برای اینکه نشون بدن این یک “استخر” (pool) است).
این دامنه ها در بخش ، “دامنه ها در طول زمان” قابل دسترس هستن.
تنوع در DLL های استفاده شده :
Puppeteer در طول سالها از نامها و مکانهای مختلف DLLها برای Sideloading یا لوود مستقیم توسط Scheduled Taskها استفاده کرده. برای نمونه :
C:\Program Files (x86)\eScan\updll3.dll3
C:\Program Files\Common Files\SYSTEM\SysResetErr\SysResetErr.DLL
C:\Program Files\Microsoft SQL Server\SpellChecking\MsSpellChecking.DLL
C:\Program Files\Microsoft SQL Server\SpellChecking\MsSpellCheckingHost.DLL
C:\ProgramData\AMD\CNext\atiadlxx.dll
C:\ProgramData\Microsoft\Assistance\LunarG\vulkan-1.dll
C:\ProgramData\Microsoft\Crypto\Escan\updll3.dll
C:\ProgramData\Microsoft\Crypto\Escan\updll3.dll3
C:\ProgramData\Microsoft\Network\Escan\AutoWake.dll
پاکسازی Puppeteer :
نمونه مورد بحث:
1c31d06cbdf961867ec788288b74bee0db7f07a75ae06d45d30355c0bc7b09fe(2020-03-09 00:57:11 UTC)
محققا همچنین پاک کننده ی Puppeteer رو هم مشاهده کردن. کارش اینه که اگه یک برنامه ی نظارتی در حال اجرا رو مشاهده کنه، DLLهای مخرب رو از روی سیستم پاک میکنه.
استقرار هر سه ماه یکبار:
نمونه مورد بحث:
1fbc562b08637a111464ba182cd22b1286a185f7cfba143505b99b07313c97a4(2021-03-01 10:43:27 UTC)
محققا در نمونه ای که بررسی کردن، متوجه شدن که استقرار بکدور هر سه ماه یکبار انجام میشه. در شکل زیر استقرار رو در ماههای مارس، ژوئن، سپتامبر و دسامبر نشون میده.
مرحله 4: بکدور:
همانطور که انتظار میره، توسعه دهندگان بدافزار که چنین تلاشی رو صرف یک حمله بدافزاری میکنن، تنها به استخراج ارز دیجیتال روی دستگاه های آلوده بسنده نمی کنن. بیایید عمیق تر به قابلیت های دیگه ی GuptiMiner نگاه کنیم، که شامل نصب دو نوع بکدور در دستگاه های آلوده میشه.
بکدور PuTTY :
نمونه مورد بحث:
07beca60c0a50520b8dbc0b8cc2d56614dd48fef0466f846a0a03afbfc42349d(2021-03-01 10:31:33 UTC)
E:\Projects\putty-src\windows\VS2012\x64\Release\plink.pdb
يكي از بکدورهایی كه توسط GuptiMiner مستقر ميشه، بر اساس يك ساخت سفارشي از PuTTY Link (plink) است. اين بیلد براي اسكن شبكه SMB محلی بهبود یافته و در نهايت، با ايجاد تونل براي ترافيك SMB از طريق دستگاه آلوده قرباني، امکان حرکت جانبی در شبكه رو براي سوء استفاده احتمالی از دستگاه های ويندوز 7 و ويندوز سرور 2008، فراهم ميكنه.
اسکن SMB محلی:
در ابتدا باینری plink ، با رویکرد سه ماه یکبار ، توسط Puppeteer به پروسس netsh.exe تزریق میشه. بعد از تزریق موفق، بدافزار با خواندن جداول IP از دستگاه قربانی، محدودههای IP محلی رو شناسایی میکنه و اونارو به لیست محدوده IP محلی و جهانی اضافه میکنه.
با داشتن این اطلاعات، بدافزار اسکن SMB محلی رو روی محدوده های IP بدست اومده (مثال: xx.yy.zz.1-254) شروع میکنه. در صورت یافتن دستگاهی که از SMB پشتیبانی میکنه، آدرس IP اون در یک لیست اختصاصی ذخیره میکنه.
بطور مشابه، IPهایی که از SMB پشتیبانی نمیکنن رو هم شناسایی کرده و برای جلوگیری از اقدامات بعدی در لیست دیگه ای (Deny List) قرار میده. این لیست سیاه در زیرکلیدهای رجیستری خاصی به نامهای Sem و Init در مسیر زیر ذخیره میشه. Init حاوی آدرسهای IP پیدا شده و Sem تعداد کل اونارو نشون میده.
1 |
HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Control\CMF\Class |
البته برای انجام چنین اسکنی شرایطی وجود داره از جمله :اسکن تنها در روزهای خاصی از هفته (!) و به صورت سه ماهه یک بار انجام میشه. همچنین، زمان اجرای اسکن بین ساعت ۱۲ ظهر تا ۶ بعد از ظهر محدود شده. هدف محققا از استفاده از علامت (!) در شرایط اسکن، اینه که بررسی روز هفته ضروری نیست (همیشه درسته).
در نهایت، بدافزار همچنین سه ساعت پس از یک اسکن موفق، یک کلید رجیستری جدید به نام HKEY_LOCAL_MACHINE\SYSTEM\RNG\FFFF ایجاد میکنه. این کلید به عنوان پرچمی عمل میکنه که اسکن باید به پایان برسه و دیگه نیازی به اسکن مجدد نیست.
باگ جالبتر مرتبط با تاریخ و زمان رو میشه در شرایط حذف رجیستری RNG\FFFF مشاهده کرد. حذف این کلید برای نشون دادن اینه که بدافزار میتونه پس از مدت زمان معینی اسکن SMB دیگه ای رو انجام بده.
همانطور که در شکل زیر مشاهده میکنید، بدافزار با استفاده از تابع SystemTimeToVariantTime API زمان نوشتن کلید رجیستری و زمان فعلی سیستم رو بدست میاره و تفاضل اونارو محاسبه میکنه. نتیجه تفاضل یک عدد اعشاریه که بخش صحیح اون نشون دهنده تعداد روزهاست.
همچنین، بدافزار از مقدار ثابت 60 * 60 * 60 * 24 = 5184000 ثانیه (60 روز) به عنوان شرطی برای حذف کلید رجیستری استفاده میکنه. با این حال، شرط، VariantTime (روز) رو با ثانیه مقایسه میکنه. بنابراین، بکدور میتونه به جای هر 60 روز (احتمالاً) هر 51.84 روز فعال بشه. به عبارتی یک ضعف پنهان که به نوعی یه موهبته!
حرکت جانبی روی ترافیک SMB :
بعد از پایان اسکن SMB، بدافزار پکت های دریافتی SMB رو بررسی میکنه که آیا آدرس های IP دریافتی شامل ویندوز 7 یا Windows Server 2008 است یا نه. اگر چنین سیستمی موجود باشه، بدافزار اونو به لیست اهداف اضافه میکنه.
همچنین GuptiMiner ، تابع اصلی main از plink رو با یسری پارامتر (شکل زیر) اجرا میکنه. این باعث ایجاد یک تونل روی پورت 445 بین سرور مهاجم ، gesucht[.]net ، و سیستم قربانی میشه.
این تونل برای ارسال ترافیک SMB از طریق دستگاه قربانی به آدرس های IP از لیست اهداف استفاده میشه و امکان حرکت جانبی در شبکه محلی رو میده.
نکته ای که محققین بهش اشاره کردن اینه که ، نسخه ی Puppeteer که این بکدور رو مستقر میکنه مربوط به سال 2021 هستش و از طرفی، ویندوز 7 و Windows Server 2008 که نسبتا قدیمی هستن رو، هدف قرار میده. محققا فکر میکنن که احتمالا یسری آسیب پذیری خاص در این سیستمهارو هدف قرار میدن.
برای هماهنگ سازی ارتباط SMB، بکدور پکت های SMB رو بصورت آنی با تغییر دادن فیلدهای TID و UID برای مطابقت با ارتباطات SMB قبلی، بصورت دستی تولید میکنه. همانطور که در کد دیکامپایل شده زیر مشاهده میکنید، packet_4 که توسط بدافزار ساخته و ارسال میشه، حاوی هر دو فیلد TID و UID از پاسخ دستگاه شبکه محلی است.
در اینجا، نمونه ای از نحوه نمایش پکتهای SMB در Wireshark توسط بدافزار رو مشاهده میکنید. پس از برقراری ارتباط، بدافزار سعی میکنه بصورت ناشناس وارد بشه و درخواست هایی برای \IPC$ و یک PIPE ارسال کنه.
نمونه فایل PCAP از این ارتباط رو میتونید از مخزن IoCها مشاهده کنید.
بکدور ماژولار:
نمونه مورد بحث:
f0ccfcb5d49d08e9e66b67bb3fedc476fdf5476a432306e78ddaaba4f8e3bbc4(2023-10-10 15:08:36 UTC)
محققا در طول تحقیقاتشون یک بکدور دیگه ای رو هم پیدا کردن که توسط Puppeteer توزیع میشه و بصورت ماژولار هستش که شبکه های سازمانی بزرگ رو هدف قرار میده. این بکدور از دو مرحله تشکیل شده :
- اسکن دستگاه برای بدست آوردن کلیدهای خصوصی ذخیره شده و کیف پول ارزهای دیجیتال
- یک بکدور ماژولار تزریق شده که به شکل شلکد هستش.
بررسی کلیدهای خصوصی، کیف های پول ارزهای دیجیتال و شبکه های سازمانی :
این قسمت از بکدور، روی اسکن فایلهای کیف پول و کلیدهای خصوصی تمرکز داره. این کار رو هم با جستجوی فایلهای pvk. و wallet. در مکانهای زیر انجام میده :
1 2 3 4 5 |
C:\Users\* D:\* E:\* F:\* G:\* |
اگه چنین فایلی در سیستم پیدا بشه، مسیر اونو در فایل زیر مینویسه:
1 |
C:\Users\Public\Ca.txt |
نکته جالب اینه که این کد پردازش خاصی روی این فایل انجام نمیده و محققا معتقدن که احتمالا بکدور یسری ماژول دیگه رو دانلود میکنه که اونا مسئول سرقت این فایل هستن.
برای مشخص کردن انجام این اسکن، بدافزار کلید رجیستری زیر رو میسازه :
1 |
HKEY_LOCAL_MACHINE\SYSTEM\Software\Microsoft\DECLAG |
اگه یسری کیف پول یا کلید خصوصی پیدا بشه یا بدافزار در یک محیط سازمانی بزرگ در حال اجرا باشه، بدافزار با تزریق بکدور به شکل شلکد در پروسس mmc.exe به اجراش ادامه میده.
برای تشخیص محیط سازمانی بزرگ از همون رویکرد Puppeteer استفاده میکنه، با این تفاوت که لیست کامیپوترهای عضو دامنه رو با مقدار 200 هزار مقایسه میکنه. یعنی اگه خروجی دستور net group برای هر کامپیوتر 25 کاراکتر بعلاوه یک خط جدید (CR+LF) برای هر سه کامپیوتر باشه، شبکه ای که حداقل 7781 کامپیوتر عضو این دامنه باشه رو هدف قرار میده.
بکدور :
نمونه مورد بحث:
8446d4fc1310b31238f9a610cd25ea832925a25e758b9a41eea66f998163bb34
این شلکد کاملا متفاوت از کدهایی است که محققین تاکنون در کمپین GuptiMiner دیدن. این کد برای ماژولار بودن طراحی شده و قابلیت اضافه کردن ماژول های بیشتر به جریان اجرا رو داره. با این حال، تنها یک ماژول ارتباطی شبکه بصورت پیش فرض، داخلش هاردکد شده و در دسترس است.
پس از تزریق، بکدور یک پیکربندی هاردکد شده و یک ماژول شبکهای هاردکد شده رو با استفاده از RC4 رمزگشایی میکنه. کلید RC4 نیز به صورت هاردکد شده و بطور مستقیم در شلکد در دسترسه.
پیکربندی شامل مواردی مانند : سروری که باید باهاش ارتباط بگیره، پورت مورد استفاده، میزان تاخیر زمانی بین دستورات/درخواستها و … هستش. دامنه ارتباطی در این پیکربندی www.righttrak[.]net:443 و یک آدرس IP:185.248.160[.]141 هستش.
ماژول شبکه هفت تا دستور پشتیبانی میکنه که لیستش رو در جدول زیر مشاهده میکنید. نکته ای که وجود داره اینه که هر ماژولی که توسط بکدور استفاده میشه، برای خودش یه همچین کنترل کننده دستوری داره.
Command | Description |
3.0 | Connect |
3.1 | Read socket |
3.2 | Write socket |
3.3 | Close socket |
4 | Close everything |
6 | Return 1 |
12 | Load configuration |
ماژولها بصورت رمزشده در رجیستری ذخیره میشن تا از ماندگاری اونا اطمینان حاصل بشه :
1 |
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCB |
بکدور همچنین برای پیدا کردن (resolve) توابع API از تکنیک “Import by hash obfuscation” استفاده میکنه. تابع هش یک الگوریتم ساده هستش که هر بایت از نام تابع اکسپورت شده رو دریافت میکنه، یک واحد به اون اضافه میکنه و بعدش عدد محاسبه شده قبلی (calculated_hash، که از ۰ شروع میشه) رو در ۱۳۱ ضرب کرده و به بایت اضافه میکنه :
سرور www.righttrak[.]net:443 اون زمان، گواهی معتبری داشته . ایمیلی هم که استفاده میکردن برای محققا جالب بوده از این نظر که ایمیلشون اصلا مشکوک نبوده. خروجی زیر از Censys گرفته شده. (Censys یکی از موتورهای جستجو برای محققین امنیتی هستش. برای مشاهده موتورهای دیگه میتونید اینجارو ببنید.)
سایر بردارهای آلودگی بکدور ماژولار:
نمونه مورد بحث:
af9f1331ac671d241bf62240aa52389059b4071a0635cb9cb58fa78ab942a33b
محققا در حین تحقیقاتشون یک اجرایی 7zip SFX رو پیدا کردن که شامل دو فایل بود:
ms00.dat
notepad.exe
notepad.exe یک باینری کوچیک هستش که فایل ms00.dat رو با استفاده از الگوریتم RC4 و کلید V#@!1vw32 رمزگشایی میکنه. فایل رمزگشایی شده ms00.dat همون بکدور ماژولار هستش که در بالا توضیح داده شد.
محققا گفتن که این فایل SFX رو ندیدن که توسط GuptiMiner توزیع بشه. این نشون میده که احتمالا این بکدور توسط بردارهای آلودگی دیگه توزیع شده.
تحقیقات مرتبط و آینده:
محققا همچنین یسری نمونه های کم و بیش مرتبط با این کمپین رو هم شناسایی کردن که در این بخش آوردنش.
اسکریپت های پاورشل:
محققا دامنه C2 که در Puppeteer مورد استفاده قرار گرفته بود رو در یسری اسکریپت پاورشل هم شناسایی کردن که در توزیع های قبلی GuptiMiner مشاهده نکرده بودن.
محققا فکر میکنن که این ممکنه نوع دیگه ای از حمله باشه که از زیرساخت GuptiMiner استفاده میکنه، هرچند ممکنه یک کمپین متفاوت باشه. اسکریپت پاورشل رو میتونید در زیر مشاهده کنید.
در این نمونه، در صورتی که آنتی ویروس روی سیستم نصب شده باشه و اسمش بیشتر از 4 حرف و با eS شروع بشه، پیلود از دامنه ی مخرب دانلود و اجرا میشه. مشخصه که توسعه دهندگان دوباره eScan AV رو هدف قرار دادن. کد مخرب همچنین زمانی اجرا میشه که نام آنتی ویروس نصب شده کمتر از 5 حرف باشه.
این اسکریپت توسط Scheduled Task و از طریق دستور زیر اجرا میشه :
1 |
"cmd.exe" /c type "\<domain>\SYSVOL\<domain>\scripts\gpon.inc" | "\<domain>\SYSVOL\<domain>\scripts\powAMD64.dat" -nop - |
در کد بالا powAMD64.dat ، یک کپی از powershell.exe هستش و اسم و مکان ذخیره شده تسک هم بصورت زیر:
1 |
C:\Windows\System32\Tasks\ScheduledDefrag |
استفاده از گواهی های سرقت شده :
محققا دو گواهی سرقت شده پیدا کردن که برای امضای پیلودهای GuptiMiner استفاده شده. نکته جالب اینه که یکی از این گواهی ها از عملیات Winnti گرفته شده که ده سال پیش کسپرسکی بهش اشاره کرده بود. البته این گواهی همچنان در بدافزارهای مختلف استفاده میشه.
جدول زیر لیست کامل گواهی های سرقت شده و موارد استفاده از اونارو نشون میده :
Stolen certificate SHA1 | Signed GuptiMiner sample |
529763AC53562BE3C1BB2C42BCAB51E3AD8F8A56 | 31dfba1b102bbf4092b25e63aae0f27386c480c10191c96c04295cb284f20878 |
529763AC53562BE3C1BB2C42BCAB51E3AD8F8A56 | 8e96d15864ec0cc6d3976d87e9e76e6eeccc23c551b22dcfacb60232773ec049 |
31070C2EA30E6B4E1C270DF94BE1036AE7F8616B | b0f94d84888dffacbc10bd7f9983b2d681b55d7e932c2d952d47ee606058df54 |
31070C2EA30E6B4E1C270DF94BE1036AE7F8616B | f656a418fca7c4275f2441840faaeb70947e4f39d3826d6d2e50a3e7b8120e4e |
احتمال ارتباط با Kimsuky :
نمونه مورد بحث:
7f1221c613b9de2da62da613b8b7c9afde2ea026fe6b88198a65c9485ded7b3d(2021-03-06 20:13:32 UTC)
محققا در طول تحقیقاتشون یک Infostealer پیدا کردن که مسیر PDB مشابهی با کمپین GuptiMiner (MainWork) داره :
1 |
F:\!PROTECT\Real\startW-2008\MainWork\Release\MainWork.pdb |
محققا گفتن که این infostealer رو ندیدن که توسط GuptiMiner توزیع شده باشه و همچنین ارتباطی با اون کمپین یا زنجیره عفونت نداره. این بدافزار کارایی مثله ضبط کلید های زده شده ، جمع آوری فرم های HTML باز شده در تب های مرورگر و … رو جمع آوری و در فایلهای لاگ ذخیره میکنه.
با این حال اون چیزی که جالبه اینه که این بدافزار مرتبط با عملیات Kimsuky هستش. Kimsuky یک گروه APT تحت حمایت کره شمالی هستش که با نام Black Banshee هم شناخته میشه.
بدافزار شامل رویکرد مشابهی برای پیدا کردن پنجره هایی با class name:49B46336-BA4D-4905-9824-D282F05F6576 (شناسایی پنجره آنتی ویروس) داره که در گزارش AhnLab و Cisco Talos Intelligence بهش اشاره شده. اگه چنین پنجره ای رو کشف کنه اونو میبنده یا از دید قربانی مخفی میکنه.
Infostealer همچنین شامل پیلود رمزنگاری شده در قسمت Resources هستش و مسیر PDB زیر داره :
1 |
F:\PROTECT\Real\startW-2008\HTTPPro\Release\HTTPPro.pdb |
این مازول از طریق الگوریتم RC4 و با کلید messi.com رمزگشایی میشه. ماژول برای دانلود مراحل اضافی و یکی از آدرس هایی زیر استفاده میشه :
1 2 |
http://stwu.mygamesonline[.]org/home/sel.php http://stwu.mygamesonline[.]org/home/buy.php?filename=%s&key=%s |
دامنه ی mygamesonline[.]org معمولا توسط Kimsuky استفاده میشه.
کیلاگر م، رحله ی بعدی رو با نام ms12.acm دانلود میکنه:
با این حرکت، الگوی احتمالی برای قرارداد نامگذاری و پیوندی به بکدور ماژولار رو میشه مشاهده کرد. همانطور که در بخش “سایر بردارهای آلودگی” توضیح داده شد، آرشیو 7z SFX حاوی یک فایل رمزگذاری شده به نام ms00.dat است که شباهت اونرو به سختی میشه نادیده گرفت.
آخرین مورد که میشه به Kimsuky مرتبطش کرد، کیلاگر Kimsuky با هش dddc57299857e6ecb2b80cbab2ae6f1978e89c4bfe664c7607129b0fc8db8b1f هستش که در گزارش Talos در موردش صحبت شده، این کیلاگر هم شامل Section بنام vlizer. هستش.
پیگیری eScan :
محققا قبل از انتشار گزارش، تحقیقات خودشون رو در اختیار eScan قرار دادن و این شرکت یک بیاینه داده :
1- سوابقشون نشون میده که آخرین گزارش مشابه رو، در اواخر سال 2019 دریافت کردن.
2- از سال 2020، یک مکانیسم بررسی دقیق رو اجرا میکنن که از EV Signing استفاده میکنه و در نتیجه باینری های بدون امضاء رو دور میریزه.
3- از یسری قوانین در راه حلشون استفاده میکنن تا هر پروسسی که برای استخراج ارزهای دیجتال استفاده میشه رو مسدود میکنه.
4- بررسی های داخلیشون، نمونه هایی از ماینر XRig رو کشف نکرده و شاید دلیلش عوامل جغرافیایی باشه.
5- آخرین نسخه ی راه حلشون از دانلود ایمن (https) و ارتباطات رمزگذاری شده استفاده میکنه تا کاربران اطمینان حاصل کنن که از طریق سرورهای ابری در حال بروزرسانی هستن.
IoCهای گزارش:
برای مشاهده ی لیست کامل IoCهای این بدافزار از این مخزن گیتهاب استفاده کنید.