IPImen ، Firewall ، NGFirewall-UTM، آیپی ایمن، فایروال ایرانی ، فایروال بومی، یوتی ام بومی، یوتی ام ایرانی، فایروال نسل بعدی ایرانی، فایروال نسل بعدی بومی

‌
بهار ٢٠٢٢ شاهد افزایش فعالیت Bumblebee loader بودیم، تهدیدی که اخیرا به دلیل ارتباط‌های زیادی که به چندین خانواده بدافزار معروف دارد، توجه زیادی را به خود جلب کرده است. در این مقاله ما نتایج تحقیقات خود را در مورد این بخش از بدافزار شرح می‌دهیم :
‌
بدافزار Bumblebee در حال تکامل دائمی است، که به بهترین وجه با این واقعیت نشان داده می‌شود که سیستم لودر دو بار در بازه زمانی چند روز دستخوش تغییر اساسی شده است؛ ابتدا با از استفاده از فایل‌های فرمت ISO گرفته تا فایل‌های با فرمت VHD حاوی اسکریپت Powershell و سپس بازگشت از نو.
‌
تغییرات در رفتار سرور‌های Bumblebee که در ژوئن ٢٠٢٢ رخ داد نشان می‌دهد که مهاجمان ممکن است تمرکز خود را از آزمایش گسترده بدافزار خود برای دسترسی به بیشترین قربانیان تغییر داده باشند.
‌
اگرچه تهدید حاوی فیلدی به نام group_name است، اما ممکن است نشانگر خوبی برای فعالیت‌های مرتبط با کلاسترینگ نباشد : نمونه‌هایی با مقادیر group_name متفاوت رفتار مشابهی از خود نشان داده‌اند، که ممکن است نشان‌دهنده یک عامل منفرد باشد که group_name‌های زیادی را اجرا می‌کند. این موضوع در مورد کلید‌های رمزگذاری صادق نیست : کلید‌های رمزگذاری مختلف همانطور که انتظار میرود، معمولا رفتار متفاوتی را نشان میدهند.
‌
اساسا Payload‌های Bumblebee، بسته به نوع قربانی بسیار متفاوت است. رایانه‌های مستقل آلوده احتمالا با تروجان‌های بانکی یا دزد‌های اطلاعاتی مورد حمله قرار می‌گیرند، در‌حالی‌که شبکه‌های سازمانی می‌توانند انتظار داشته باشند که با ابزار‌های پیشرفته‌تر پس از بهره‌برداری مانند CobaltStrike ضربه بخورند.
‌
تجزیه‌ و‌ تحلیل Bumblebee
لودر Bumblebee معمولا به شکل یک باینری شبیه به DLL است که با یک پکر سفارشی پک شده است. به نظر می‌رسد روشی که این DLL ارائه می‌شود با توجه به خواسته‌های توسعه‌دهندگان دنبال کننده تهدید، در معرض تغییر است : در‌حالی‌که روش غالب این است که DLL پک شده را مستقیما در یک فایل دیگر (معمولا ISO) جاسازی کنند، در طی یک دوره کوتاه در ژوئن، اپراتور‌های بدافزار با استفاده از فایل‌های VHD آزمایش کردند که PowerShell بارگیری و رمزگشایی خود DLL پک‌شده (با پکر‌های بسیار متفاوت) را اجرا می‌کرد،  که توسط Deep Instinct مستند شده است. به نظر می‌رسد که این‌روند از بین رفته است و اکنون می‌توان DLL را مستقیما در فایل مرحله اول، چه ISO و چه VHD، به‌طور مستقیم یافت.
‌
پس از باز کردن پک‌ها، Bumblebee بررسی‌هایی را انجام می‌دهد تا در محیط‌های sandboxing یا تحلیلگر اجرا نشود. بیشتر کد‌های مسئول این کار متن باز است که مستقیما از پروژه Al-Khaser برداشته شده است. اگر این بررسی‌ها انجام شود، Bumblebee اقدام به بارگذاری پیکربندی خود در حافظه می‌کند. این کار با بارگیری چهار پوین‌تر از بخش داده‌های آن انجام می‌شود که به چهار بافر مختلف در یک ساختار پیکربندی رمزگذاری‌شده به‌هم پیوسته اشاره می‌کنند. اولین مورد از اینها به بخش ٨٠ بایتی اشاره می‌کند که یک کلید ascii RC4 را ذخیره می‌کند (در همه مواردی که مشاهده کردیم بسیار کوتاه‌تر است). سه نشانگر دیگر به دو بخش ٨٠ بایتی و یک بخش ١٠٢٤ بایتی اشاره می‌کنند که همه آنها حاوی داده‌هایی هستند که سپس با استفاده از کلید RC4 فوق رمزگشایی می‌شوند.
‌
پس از رمزگشایی، اولین بافر ٨٠ بایتی در بسیاری از نمونه‌ها تا به امروز به سادگی حاوی عدد "444" است. بدافزار از این عدد استفاده نمی‌کند، بنابراین اهمیت آن مشخص نیست. بافر دوم حاوی یک کد ASCII است که توسط بدافزار group_name نامیده می‌شود. در‌نهایت، بلوک ١٠٢٤ بایتی حاوی لیستی از سرور‌های command-and-control است (اکثر آنها معمولا جعلی هستند).
‌

‌
بدافزار Bumblebee یک شناسه قربانی شبه تصادفی مخصوص ماشین (با نام داخلی Client_id) را از طریق روش معمول الحاق برخی پارامتر‌های ماشین تغییرنا‌پذیر (در این مورد، نام ماشین و GUUID) و سپس محاسبه هش از نتیجه (در این مورد، خلاصه MD5) محاسبه می‌کند.
‌
با استفاده از این داده‌ها و برخی عناصر دیگر جمع‌آوری‌شده از سیستم قربانی، Bumblebee یک بررسی C&C در قالب JSON می‌سازد، مانند شکل زیر :
‌

‌
این رشته با استفاده از همان کلید RC4 که قبلا برای پیکربندی استفاده شده بود، رمزگذاری می‌شود و به طور مکرر به سرور C2 خود با تاخیر‌های تصادفی بین ٢۵ ثانیه تا ٣ دقیقه بدون در نظر گرفتن اینکه سرور پاسخ می‌دهد یا از کار افتاده است، ارسال می‌شود. پاسخ سرور C2 نیز به فرمت JSON است و همچنین با همان کلید RC4 رمزگذاری شده است (ما از این طراحی زیبا قدردانی می‌کنیم و نویسندگان بدافزار را تشویق می‌کنیم تا این استاندارد خوانایی را دنبال کنند).
‌
محتوای پاسخ به طور طبیعی متفاوت است و می‌تواند برای مثال یک پاسخ خالی باشد :
‌

‌
یا مقداری paylaod برای تزریق یا اجرا :
‌

‌
در مورد دریافت payload، ساختار پاسخ شامل فهرستی از عناصر در بخش وظایف json خواهد بود که هر‌کدام دارای یک فرمان و یک payload است. هر یک از عناصر، از‌جمله، شامل یک فیلد کار با نام فرمانی که باید اجرا شود، و یک payload کدگذاری شده base64 در داخل بخشی به نا‌م task_data خواهد بود.
‌
تجزیه‌  و‌تحلیل رفتار بات نت
تا اوایل ژوئیه ما رفتار بسیار کنجکاوانه سرور‌های command-and-control را مشاهده کرده‌ایم. هنگامی که یک client_id برای یک قربانی آلوده ایجاد شد و به سرور command-and-control ارسال شد، آن سرور C2 دیگر کدهای client_id از همان IP خارجی قربانی را نمی‌پذیرد. این بدان معناست که اگر چندین کامپیوتر در یک سازمان که با همان IP عمومی به اینترنت دسترسی دارند آلوده شوند، سرور C2 فقط اولین مورد آلوده را می‌پذیرد. اما چندین هفته پیش این ویژگی به طور ناگهانی غیرفعال شد، و تعداد اتصالات برقرار شده با قربانیان آلوده را به‌شدت افزایش داد به بهای هر چیزی که این ویژگی قرار بود به آن برسد (احتمالا نشان‌دهنده مرحله آزمایشی برای بدافزار بود که اکنون به‌پایان رسیده است).
‌
این رفتار ما را بر آن داشت تا به رفتار Bumblebee در محیط‌های مختلف اجرایی توجه ویژه‌ای داشته باشیم. قابل ذکر است، علیرغم وجود فیلدی به نام group_name در هر نمونه، این مقدار در هر درخواست به سرور command-and-control ارسال می‌شود. علاوه بر این، به نظر می‌رسید که سیاست توصیف‌شده «یک client_id برای هر آدرس IP» به طور عجیبی در نام‌های گروه‌های مختلف اعمال می‌شود - اما نه در کلید‌های رمزگذاری RC4 مختلف، که به نظر می‌رسد به معنای استفاده از چندین group_name توسط چیزی است که عملا یک بات‌نت و احتمالا برای علامت‌گذاری کمپین‌های مختلف یا مجموعه‌های مختلف قربانیان است. در نتیجه، به نظر می‌رسد گروه‌بندی فعالیت‌ها بر اساس کلید رمزگذاری، رویکرد منسجم‌تری نسبت به گروه‌بندی براساس group_name باشد.
‌
این فرضیه بیشتر با این واقعیت پشتیبانی می‌شود که ما چندین نمونه با کلید RC4 یکسان و نام گروهی متفاوت را مشاهده کرده‌ایم که به طور یکسان عمل می‌کنند و تهدیدات یکسانی را در یک بازه زمانی بسیار نزدیک حذف می‌کنند، در‌حالی‌که نمونه‌هایی که در کلید RC4 استفاده‌شده متفاوت هستند و رفتار کاملا متفاوتی از خود نشان می‌دهند.
‌

‌
این واقعیت که سرور‌های C2 با آدرس‌های IP مختلف که نمونه‌های مختلف با استفاده از یک کلید RC4 با آن‌ها تماس گرفته‌اند، paylaod‌های یکسانی را برمی‌گردانند و همان «client_id» را برای قربانیان خود مسدود می‌کنند، همچنین نشان می‌دهد که این آدرس‌های IP در‌واقع فقط به‌عنوان فرانت برای یک Command-and-control اصلی عمل می‌کنند که سروری است که تمام اتصالات Bumblebee به آن منتقل می‌شود.
‌
یکی دیگر از عناصر جالب رفتار این بات‌نت‌ها این است که چگونه مجموعه ابزاری که توسط Bumblebee در ماشین‌های قربانی مستقر شده، بسته به نوع هدف متفاوت است. برای استقرار یک تهدید، از ۵ فرمان پشتیبانی شده توسط bumblebee، سه فرمان منجر به دانلود کد از سرور C2 و اجرا می‌شود :
‌
DEX : یک فایل اجرایی را روی دیسک مستقر می‌کند و آن را اجرا می‌کند.
‌
DIJ : یک لایبرری را به یک فرآیند تزریق می‌کند و آن را اجرا می‌کند.
‌
SHI : یک shellcode را به یک فرآیند تزریق و اجرا می‌کند.

‌به‌عنوان بخشی از مانیتورینگ مداوم بر بات‌نت‌های مختلف Bumblebee، ما بر اساس عواملی مانند نوع شبکه یا موقعیت جغرافیایی، تفاوت‌های رفتاری را زیر نظر گرفته‌ایم. در‌حالی‌که به نظر نمی‌رسید موقعیت جغرافیایی قربانی تاثیری بر رفتار بدافزار داشته باشد، ما تفاوت بسیار فاحشی را بین نحوه رفتار Bumblebee پس از آلوده کردن ماشین‌هایی که بخشی از یک دامنه هستند (گروه منطقی از شبکه که اکتیو دایرکتوری سرور یکسانی دارند)، بر خلاف ماشین‌های جدا شده از یک شبکه شرکتی که به یک گروه کاری متصل هستند (اصطلاح مایکروسافت برای نشان دادن شبکه محلی peer to peer) مشاهده کردیم.
‌
اگر قربانی به WORKGROUP متصل باشد، در بیشتر موارد فرمان DEX (دانلود و اجرا) را دریافت می‌کند که باعث می‌شود فایلی را از دیسک رها کرده و اجرا کند. این payload‌ها معمولا دزد‌های معمولی مانند Vidar Stealer یا تروجان‌های بانکی هستند :
‌

‌
از طرف دیگر، اگر قربانی به یک دامنه AD متصل باشد، به‌طور‌کلی دستورات DIJ (دانلود و تزریق) یا SHI (دانلود shellcode و تزریق) را دریافت می‌کند.
‌

‌
در این موارد، تهدیدات حاصل از فریمورک‌های پیشرفته‌تر پس از بهره‌برداری، مانند CobaltStrike، Sliver یا Meterpreter بوده است.
‌
در این موارد، همچنین مشاهده شده است که بدون توجه به IP سرور command-and-cobtrol و فیلد group_name، نمونه‌هایی با کلید RC4 یکسان، همان بیکون‌های Cobalt Strike را با همان سرور‌های Team رها می‌کنند، که کارآمد بالای آن ثابت شده است و ابزار مفیدی برای ارتباط نمونه‌های مختلف به یکدیگر به‌عنوان بخشی از یک بات نت هستند.
‌
آخرین ویژگی جالب paylaod‌های رها شده توسط Bumblebee این است که هم باینری‌های دانلود شده با استفاده از دستور DEX و هم آنهایی که با دستور DIJ دانلود می‌شوند در بسیاری از موارد با استفاده از پکر‌های Bumblebee یکسان پک می‌شوند.
‌
نتیجه‌گیری
با تجزیه‌و‌تحلیل رفتار سرور‌های command-and-control مورد استفاده توسط اپراتور‌های Bumblebee، مشاهده کرده‌ایم که آنها چگونه رفتار زنجیره‌های آلودگی خود را بهینه‌سازی کرده‌اند، که گاهی اوقات به روش‌هاییست که تعداد قربانیان فعال و حجم ترافیک C2 را افزایش می‌دهد.
‌
در حال حاضر، رفتار تا زمان استقرار paylaod مرحله دوم حتی در بات‌نت‌های مختلف Bumblebee بسیار مشابه است، اما رفتار بعدی که با انتخاب paylaod مرحله دوم شروع می‌شود، به‌شدت بر اساس کلید RC4 مورد استفاده متفاوت است. این رفتار همچنین می‌تواند برای گروه‌بندی فعالیت‌ها در کلاستر‌های مختلف، علاوه بر استفاده از خود کلید RC4، مفید باشد.
‌
برخلاف سایر تهدید‌ها که از پکر‌های شخص ثالث و ابزار‌های فرار از آنتی‌ویروس استفاده می‌کنند، Bumblebee مانند سایر خانواده‌های بدافزار پیشرفته، هم برای خود تهدید و هم برای برخی از نمونه‌هایی که روی رایانه‌های قربانیان مستقر می‌کند، از پک کننده‌های خاص خود استفاده می‌کند، مانند Trickbot. در‌حالی‌که این به اپراتور‌های Bumblebee انعطاف بیشتری در تغییر رفتار و افزودن ویژگی‌ها می‌دهد، استفاده از ابزار‌های سفارشی منحصر‌به‌فرد نیز به‌عنوان روشی برای شناسایی سریع فعالیت Bumblebee در فضای سایبری عمل می‌کند.