IOCONTROL بخشی از عملیات سایبری علیه دستگاههای اینترنت اشیاء (IOT) و فناوری عملیاتی (OT) غربی هستش. دستگاه های تحت تأثیر شامل روترها، PLC، HMI، فایروال ها و سایر پلتفرم های IOT/OT مبتنی بر لینوکس میشه. در حالیکه اعتقاد بر اینه که این بدافزار توسط یک بازیگر تهدید ساخته شده، به نظر میرسه که این بدافزار به اندازه کافی عمومیه که بدلیل پیکربندی ماژولار خودش، قادر به اجرا روی طیف گسترده ای از پلتفرم های مختلف از فروشندگان مختلف هستش.
IOCONTROL برای حمله به دستگاههای IoT و SCADA از انواع مختلف از جمله دوربین‌های IP، روترها، PLCها، HMIها، فایروال‌ها و موارد دیگه از فروشندگان مختلف مانند Baicells، D-Link، Hikvision، Red Lion، Orpak، Phoenix Contact، Teltonika، Unitronics و … قابل استفاده هستش.
فناوری عملیاتی (Operational Technology) یا به اختصار OT به مجموعه‌ای از سیستمها، نرم‌افزارها و سخت‌افزارهایی گفته میشه که برای کنترل و نظارت بر فرآیندهای فیزیکی در صنایع مختلف استفاده میشه. این فناوریها بطور مستقیم با دنیای فیزیکی تعامل دارن و برای مدیریت و کنترل تجهیزات صنعتی، زیرساختها و سیستمهای تولیدی بکار میرن.
اینترنت اشیا یا IoT به شبکه‌ای از اشیاء فیزیکی گفته میشه که به اینترنت متصل هستن و میتونن داده‌ها رو جمع‌آوری، پردازش و با یکدیگر یا با سیستمهای دیگه تبادل کنن. این اشیاء میتونن از سنسورهای ساده تا دستگاههای پیچیده‌تر مانند خودروهای هوشمند، تجهیزات پزشکی و دستگاههای خونگی هوشمند باشن.
محققای Team82، یک نمونه از این بدافزار رو از یک سیستم مدیریت سوخت استخراج و آنالیز کردن و معتقدن که این سیستمها توسط یک بازیگر مرتبط با ایران بنام CyberAv3ngers، که قبلا حمله ی Unitronics رو انجام داده بود، هک شدن.
یک موج حمله ی خاص IOCONTROL، شامل آلوده شدن چند صد سیستم Orpak ساخت اسرائیل و سیستمهای مدیریت سوخت Gasboy ساخت آمریکا در اسرائیل و آمریکا میشه. این بدافزار بصورت خاص برای دستگاههای اینترنت اشیاء ساخته شده اما تاثیری مستقیمی روی دستگاههای OT مانند پمپ های سوخت که در پمپ های بنزین استفاده میشه، داره.
این حملات نشون دهنده گسترش درگیری های ژئوپلیتیکی بین اسرائیل و ایران هستش. احتمال میدن که گروه هکری CyberAv3ngers وابسته به سپاه هستش و معمولا از طریق کانال تلگرامیشون اسکرین شاتهایی از اهدافشون منتشر میکنن.
در ماه فوریه، وزارت خزانه داری آمریکا، شش مقام مرتبط با CyberAv3ngers رو تحریم کرد.
محققا با بررسی یک نمونه از این بدافزار که از VirusTotal بدست آوردن (21 تشخیص تا 10 دسامبر 2024، پس از دوره‌ای که تا سپتامبر 2024 هیچ تشخیصی وجود نداشت) معتقدن که این بدافزار، یک سلاح سایبری هستش که توسط یک دولت-ملت برای حمله به زیرساختهای غیرنظامی توسعه داده شده. حداقل یکی از قربانیان سیستمهای مدیریت سوخت Orpak و Gasboy بودن.
برای برقراری ارتباط امن بین دستگاههای آلوده و مهاجمان، IOCONTROL از پروتکل MQTT بعنوان یک کانال ارتباطی اختصاصی IoT استفاده میکنه. مهاجمان تونستن ترافیک بین C2 رو از طریق MQTT مخفی کنن.
از سوی دیگه، گروه سایبری CyberAv3ngers بطور ضمنی اعلام کرده که به هدف قرار دادن فناوریهای ساخت اسرائیل در زیرساختهای حیاتی ادامه میده. در اکتبر 2023، تأسیسات تصفیه آب در ایالات متحده و اسرائیل توسط این گروه مورد حمله قرار گرفت. دستگاههای PLC/HMI سری Integrated Unitronics Vision در داخل این تأسیسات هک شدن. این حملات احتمالاً نمایش قدرت از سوی CyberAv3ngers بود و نشون دهنده دسترسی اونا به دستگاهها و امید به ایجاد ترس در مورد کیفیت آب در مناطق آسیب دیده بود.
استقرار IOCONTROL روی سیستمهای ORPAK:
همون زمانی که حملاتی به تاسیسات آب انجام داده بودن، گروه سایبری CyberAv3ngers در تلگرام ادعا کرد که 200 پمپ بنزین در اسرائیل و ایالات متحده رو هدف قرار داده. این حملات بطور خاص سیستمهای Orpak رو هدف قرار داده بود. مهاجمان اسکرین شاتهایی از پورتال مدیریت اصلی پمپ بنزین ها و همچنین داده ها و اطلاعات دیتابیس، از اهداف خودشون رو منتشر کردن.
پس از ادعای CyberAv3ngers مبنی بر به خطر انداختن سیستمهای Orpak، محققا سوابق WHOIS رو بررسی کردن که نشون دهنده ثبت دامنه tylarion867mino[.]com در 23 نوامبر 2023 | 2 آذر 1402 هستش. این دامنه توسط مهاجمان برای راه‌اندازی یک زیرساخت C2، بمنظور مدیریت همه دستگاههای آلوده استفاده میشد.
در دسامبر 2023| 27 آذر 1402، یک گروه هکری وابسته به اسرائیل به نام گنجشک درنده ادعا کرد که 70 درصد از پمپ بنزینهای ایران رو مورد حمله و هک قرار داده و ادعا کرد که این کار “در پاسخ به تجاوز جمهوری اسلامی و نیابتیهاش در منطقه” انجام شده. برای آشنایی بیشتر با حملات این گروه، گزارش آقای حمید کشفی در خصوص حمله ی اول این گروه در سال 1400 رو که در 4 قسمت منتشر کردیم رو مطالعه کنید.
در حالیکه گزارشهای مربوط به این حملات توسط CyberAv3ngers علیه دستگاههای Orpak از اواسط اکتبر 2023 تا اواخر ژانویه 2024 (اواسط مهر 1402 تا اواسط بهمن 1402) گسترده است، محققا یک نمونه عمومی شده از IOCONTROL رو از VirusTotal دریافت کردن که نشون میده این گروه در ماههای جولای و آگوست (تیر و مرداد 1403) کمپین هدفمند خودش رو مجدداً راه‌اندازی کرده.
در این پست تحلیل محققا از حمله به چندین دستگاه IoT/OT، از جمله دستگاههای Orpak و Gasboy ارائه شده. همچنین، تحلیل بدافزار IOCONTROL مورد استفاده در حملات، زیرساخت C2 و ارتباطات از طریق پروتکل MQTT بررسی شده.
دستگاههای ORPAK Systems :
نمونه‌ای که محققا تونستن بدست بیارن از یک سیستم کنترل سوخت Gasboy استخراج شده که ارتباط نزدیکی با سیستمهای Orpak داره. هنوز مشخص نیست که از چه روشی برای استقرار بدافزار در سیستمهای قربانی، استفاده کردن.
سیستمهای کنترل سوخت پلتفرمهای پیچیده‌ای هستن که از چندین زیرسیستم از جمله یک ترمینال پرداخت بیرونی، چاپگر (برای رسید)، کنترل پمپ و نازل و لوازم جانبی دیگه مانند نرم‌افزار مدیریت و صورتحساب تشکیل شدن.
IOCONTROL در ترمینال پرداخت Gasboy به نام OrPT مخفی شده بود. مهاجمی که کنترل کاملی بر ترمینال پرداخت داشت، توانایی خاموش کردن خدمات سوخت و احتمالاً سرقت اطلاعات کارت اعتباری مشتریان رو هم داشته.
آنالیز IOCONTROL :
نمونه ای از IOCONTROL که دستگاههای سیستم سوخت Orpak رو هدف قرار میداد و محققا بررسیش کردن، هش زیر داره:
|
1 |
1b39f9b2b96a6586c4a11ab2fdbff8fdf16ba5a0ac7603149023d73f33b84498 |
نمونه دارای GUID زیر بود که برای شناسایی قربانی مورد استفاده قرار میگیره:
|
1 |
855958ce-6483-4953-8c18-3f9625d88c27 |
نمونه ای که محققا آنالیز کردن بطور خاص برای سیستمهایی با معماری ARM-32 bit Big Endian کامپایل شده.
آنپک و شبیه سازی IOCONTROL:
محققا وقتی این نمونه رو در VirusTotal مشاهده کردن، هیچکدوم از سندباکسهای VirusTotal اونو شناسایی نکرده بودن. از 10 دسامبر، 21 مورد از سندباکسها، اونو بعنوان بدافزار شناسایی کردن.
محققا با دونستن این قضیه، در مدیریت بدافزار و آنالیز اجزای داخلی اون، محتاط تر شدن. برای شروع آنالیز، رفتن سراغ آنالیز استاتیک. با آنالیز استاتیک متوجه شدن که بدافزار موقع اجرا، یک تابع آنپک کردن رو در مموری قرار میده.
زمان زیادی رو در آنالیز استاتیک صرف کردن و در ادامه برای کشف موارد بیشتر، رفتن سراغ آنالیز داینامیک. آنالیز داینامیک یعنی اینکه محققا باید بتونن بدافزار رو در یک محیط امن اجرا و دیباگش کنن.
برای این کار رویکردی که داشتن، استفاده از شبیه ساز بود. برای این مورد هم از Unicorn CPU که مبتنی بر پایتون هستش، استفاده کردن.
محققا گفتن، به دو دلیل، این رویکرد رو انتخاب کردن:
- بدافزار در معماری قدیمی ARM 32-bit BE CPU توسعه داده شده، بنابراین شبیه سازی بهترین گزینه برای اجرا و آنپک کردن اون هستش.
- بدافزار باید در یک محیط امن اجرا میشد تا سیستم رو آلوده نکنه و فعالیت مخربی روی سیستمها انجام نده.
Unicorn کنترل بیشتری نسبت به شبیه سازهای دیگه ای مانند QEMU میده. با استفاده از Unicorn، نه تنها تونستن جریان اجرای بدافزار رو بررسی کنن، بلکه کنترل بیشتری روی قابلیتهای بدافزار، با توجه به اینکه با سیستم عامل تعامل داره و از Syscallها استفاده میکنه، داشته باشن.
شبیه‌سازی نمونه IOCONTROL یک فرآیند تدریجی بود که در اون محققا جریان اجرای بدافزار رو با دقت بررسی کردن. این شامل ردیابی کد اجرا شده و ذخیره نگاشت‌های حافظه در هر دور شبیه‌سازی بود. در ابتدا، هر دور شبیه‌سازی بطور ناگهانی و اندکی پس از شروع اجرای نمونه، متوقف میشد. این اغلب به دلیل تلاش برای فراخوانی یک syscall برای تعامل با سیستم‌عامل توسط بدافزار رخ میداد. Unicorn قابلیت اجرای دستورالعمل‌های پردازنده شبیه‌سازی شده رو در معماریها و تغییرات مختلف فراهم میکنه. با این حال، زیرساختهای خاص سیستم‌عامل، مانند پیاده‌سازیهای syscall سیستم‌عاملهای خاصی، مانند لینوکس یا ویندوز رو تسهیل نمیکنه.
محققا هر بار که با تلاش برای فراخوانی یک syscall خاص مواجه شدن، سعی کردن هدف اونو درک کنن و نسخه خودشون رو از اون syscall پیاده‌سازی کنن، که بتونن اجرا رو ادامه بدن و در عین حال اطمینان حاصل کنن که تعامل ایمن هستش و به محیط آزمایش آسیب نمیرسونه.
مثلا، وقتی اجرایی از syscallهای open و read برای خوندن فایلی از سیستم فایل رو فراخوانی میکرد، هوک اجرای دستورالعمل محققا فعال شده و این فراخوانیها رو مدیریت میکرد. در این حالت، هنگامیکه یک syscall open فراخوانی میشد، هوک محققا یک مقدار fd جعلی رو برای شناسایی فایل درخواست شده برمیگردوند. وقتی که روی یک syscall read فعال میشد، محتوای تعریف شده محققا رو، ارائه میداد. انجام این کار به محققا این امکان رو میداد که دسترسی دقیقی به جریان کد بدافزار داشته باشن.
آنپک کردن در مموری، در 2 مرحله انجام میشده. در مرحله اول، بخشی از کد بدافزار که وظیفه آنپک کردن خودش رو بر عهده داشت، به یک ناحیه جدید در حافظه منتقل شده. در مرحله دوم، ماژول اجرایی اصلی و پیکربندی بدافزار آنپک و به یک ناحیه مناسب در حافظه منتقل میشه.
در یکی از تکرارهای شبیه‌سازی، جریان اجرا، شروع به اجرای یک بخش حافظه جدید نگاشت شده کرد. این بدین معنی که این بخش حافظه دارای یک مصنوع آنپک شده بود. محققا با بررسی این بخش از مموری، متوجه شدن که هکرها از یک پکر متن باز بنام UPX استفاده کردن که ممکنه بطور خاص برای این نمونه بدافزار اصلاح شده باشه. چیزی که باعث شده به این پکر برسن وجود رشته ی “!XPU” بوده که در نسخه little endian از “UPX” هستش. این اشتباه مهاجمان به محققا کمک کرده تا به سرعت UPX رو به عنوان پکر شناسایی کنن.
محققا که الان نسخه ی آنپک شده ی بدافزار رو دارن، برای تحقیق بیشتر، اومدن دوباره بدافزار آنپک شده رو با نسخه ی UPX قانونی پکش کردن و اونو با نسخه ی اصلی بدافزار (قبل از آنپک شدن) مقایسه کردن تا ببینن چه تفاوتهایی بینشون هستش. محققا متوجه یسری تغییرات شدن از جمله رشته مجیک !UPX که به !ABC تغییر داده شده بود.
محققا برای اینکه این نتیجه گیری رو تایید کنن، اومدن نسخه ی قانونی UPX رو دستکاری کردن و یک نسخه ی جدید رو کامپایل کردن که UPX رو به ABC تبدیل میکرده و CRC رو هم نادیده میگرفته و باهاش بدافزار رو با موفقیت آنپک کردن.
محققا احتمال میدن که مهاجمها بدافزار رو با این روش مستقر کردن چون سعی داشتن از تشخیص جلوگیری کنن و ایمپلنت مخرب و پیکربندی خودشون رو به روشی پایدار و سریع مخفی کنن. ظاهراً این تا حدودی در زمینه مخفی موندن از موتورهای تشخیص خودکار مؤثر بوده، اما خیلی پیچیده نبود.
رمزگشایی تنظیمات IOCONTROL :
محققا بعد از اینکه تونستن با موفقیت بدافزار رو آنپک کنن به دو مصنوع رسیدن: یک بخش داده رمزگذاری شده (encrypted data section) و یک فایل اجرایی. هنگام بررسی فایل اجرایی در IDA، متوجه شدن که در بسیاری از مکانهای مختلف در کد، از بخش داده های رمزگذاری شده استفاده میکنه و از اون برای عملیات مختلفی مانند مسیر یک فایل، آدرس IP برای اتصال و غیره استفاده میکنه.
محققا متوجه شدن که این بخش داده رمزشده، در حقیقت پیکربندی بدافزار هستش که بصورت رمز شده هستش. هر ردیف از این پیکربندی رمز شده از 150 بایت تشکیل شده: بایت اول نشون دهنده سایز کلی ردیف هستش که حداکثر عدد 149 رو شامل میشه و بقیه هم نشون دهنده داده ها هستش که حداکثر 149 بایت داده رو شامل میشه.
برای رمزگشایی پیکربندی بدافزار، از یک تابع رمزگشایی استفاده میکنه. این تابع اندیس ردیفی که بدافزار بهش نیاز داره رو دریافت و اونو رمزگشایی میکنه. با توجه به اینکه نیومده همه ی پیکربندی رو یکجا رمزگشایی کنه، اینجوری میشه از حافظه ی پروسس کل پیکربندیها رو دامپ کرد و آنالیز ساده تر میشه و بجاش از اندیس و رمزگشایی بصورت تکی استفاده کرده که امکان استخراج پیکربندی رو به حداقل رسونده.
در این تابع رمزگشایی، بدافزار اولین بایت رو از ورودی پیکربندی رمزگذاری شده دریافت میکنه. این مقدار برای تعیین طول اون ورودی پیکربندی رمزگذاری شده خاص استفاده میشه. بعد از خوندن بایتهای خام ورودی رمزگذاری شده، بدافزار از AES-256-CBC برای استخراج ورودی پیکربندی واقعی استفاده میکنه.
قبل از رمزگشایی، بدافزار جفت کلید و IV رو از یک GUID ذخیره شده در یکی از رشته‌های خودش استخراج میکنه که بدافزار برای اهداف بسیاری ازش استفاده میکنه. کلید و IV استخراج شده برای رمزگشایی استفاده میشن و به ترتیب در متغیرهای محیطی 0_0 و 0_1 ذخیره میشن.
همونطور که مشاهده میکنید، بدافزار GUID ذخیره شده در حافظه خودش رو (855958ce-6483-4953-8c18-3f9625d88c27) میگیره و از SHA256 برای هش کردنش استفاده میکنه. کلید رمزگذاری AES-256-CBC به سادگی هش GUID (22e70a3056aa209e90dc5a354edda2c1c3b88f1e4720dc6a090c4617a919447e) به عنوان یک رشته هگزادسیمال هستش. این احتمالاً اشتباهی از سوی مهاجمان است که گیج شدن، چون AES-256 از اندازه 32 بایتی برای کلیدهای خودش استفاده میکنه، اما هکرها بجای 32 از یک رشته 64 هگزی استفاده کردن. از آنجایی که کلید داده شده بزرگتر از اندازه کلید هستش، در واقع فقط 32 بایت اول توسط فرآیند AES-256-CBC استفاده میشه. IV مورد استفاده برای رمزگذاری، یک زیر رشته از اون هش هستش (از اندیس 31 تا اندیس 63). باز هم IV خیلی طولانیه، بنابراین فقط 16 بایت اول استفاده میشه.
محققا حدس میزنن که مهاجمان از GUIDهای منحصر به فرد استفاده میکنن که با وصله (Patch) باینری نمونه‌های بدافزار انجام میشه تا بین قربانیان و/یا کمپینهای مختلف تمایز قائل بشن. این با این واقعیت بیشتر پشتیبانی میشه که بدافزار بیشتر پارامترهای خودش رو از GUID اصلی استخراج میکنه که میتونه اونو به راحتی بدون کامپایل مجدد بدافزار با اصلاح رشته در باینری تغییر داد. علاوه بر این، بدافزار از شناسه‌های فروشنده IoT استفاده میکنه. مثلا، در نمونه ای که محققا بررسی کردن، نام Orpak رو در پیکربندی رمزگشایی شده مشاهده کردن که مشخص کننده فروشنده دستگاه تعبیه شده مورد حمله، هستش.
برای خلاصه، در اینجا متغیرهای محیطی استفاده شده توسط بدافزار، نحوه استفاده از اون و نحوه تولید اونا آورده شده:
| متغیر محیطی | مقدار | نحوه بدست اومدن | کاربرد |
|---|---|---|---|
| GUID - متغیر محیطی نیستش | 855958ce-6483-4953-8c18-3f9625d88c27 | هاردکد شده | ایجاد شناسه برای بدافزار |
| 0_0 | 22e70a3056aa209e90dc5a354edda2c1c3b88f1e4720dc6a090c4617a919447e | SHA256(GUID) | کلید AES-256-CBC برای رمزگشایی پیکربندی |
| 0_1 | 1c3b88f1e4720dc6a090c4617a919447 | SHA256(GUID)[31:63] | کلید IV در AES-256-CBC برای رمزگشایی پیکربندی |
| 1 | 1.0.5 | هاردکد شده | نسخه ی بدافزار |
| 3 | 5958ce | GUID[2:8] | مقداری که بدافزار میگه خودش حذف کنه. همچنین بعنوان نام کاربری MQTT استفاده میشه |
| 4 | 3-4953-8c18-3f9625 | GUID[12:30] | بعنوان پسورد MQTT استفاده میشه. |
محققا بعد از استخراج IV و کلید AES-256-CBC، کل بخش رمزشده که حاوی پیکربندی بود رو رمزگشایی و اونا رو بررسی کردن.
یافتن C2 IOCONTROL از طریق DoH:
الان که محققا پیکربندی رو داشتن، رفتن سراغ رفتار بدافزار. اولین چیزی که توجهشون رو جلب کرده، نام DNS ذخیره شده در پیکربندی بوده:
|
1 |
uuokhhfsdlk[.]tylarion867mino[.]com |
در زمان نگارش این گزارش، آدرس C2 دامنه به آدرس IP 159[.]100[.]6[.]69 حل (resolving) می شد.
محققا بعد از دنبال کردن جریان اجرای بدافزار، متوجه شدن که این همون Hostname هستش که بدافزار برای برقراری ارتباط با C2 خودش ازش استفاده میکنه.
ابتدا، بدافزار از سرورهای Cloudflare برای ترجمه Hostname به آدرس IP استفاده میکنه. برای جلوگیری از تشخیص، بدافزار از DNS برای ترجمه مستقیم این Hostname استفاده نمیکنه، بلکه از DNS over HTTPS (DoH) و از طریق API CloudFlare استفاده میکنه.
DNS یا سیستم نام دامنه، آدرس‌های IP رو به نامهای دامنه (مثل onhexgroup.ir) تبدیل میکنه تا ما به جای حفظ اعداد طولانی، بتونیم از نامهای ساده برای دسترسی به وب‌سایت‌ها استفاده کنیم. بطور سنتی، درخواستهای DNS بصورت متن ساده ارسال میشن، که این امر باعث میشه اطلاعات حساس در مورد سایت‌هایی که بازدید میکنید، قابل مشاهده باشن. DoH این درخواستها رو رمزگذاری میکنه تا حریم خصوصی شما حفظ بشه.
این یک تکنیک مخفی کاری هستش که توسط بدافزار برای جلوگیری از تشخیص با ارسال درخواست DNS متن ساده استفاده میشه و نشون میده که اونا با کدوم نامهای DNS ارتباط برقرار میکنن. برای حل این مشکل هم اونا از یک پروتکل رمزگذاری شده (HTTPS) استفاده کردن، به این معنی که حتی اگه یک Network Tap (ابزاری که یک کپی از تمام یا بخشی از ترافیک شبکه میگیره و اونو برای تحلیل و بررسی به یک سیستم دیگه هدایت میکنه.) وجود داشته باشه، ترافیک رمزگذاری شده هستش، بنابراین اونا کشف نخواهند شد.
در زیر درخواست به سرورهای Cloudflare برای پرسیدن Hostname C2 مهاجم اومده:
|
1 2 |
~ curl --http2 --header "accept: application/dns-json" "https://1.1.1.1/dns-query?name=uuokhhfsdlk[.]tylarion867mino[.]com" |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
{ "Status": 0, "TC": false, "RD": true, "RA": true, "AD": false, "CD": false, "Question": [ { "name": "uuokhhfsdlk[.]tylarion867mino[.]com", "type": 1 } ], "Answer": [ { "name": "uuokhhfsdlk[.]tylarion867mino[.]com", "type": 1, "TTL": 300, "data": "159[.]100[.]6[.]69" } ] } |
ماندگاری (Persistence):
بدافزار قبل از اینکه به C2 وصل بشه، یک بکدور روی دستگاه نصب میکنه تا از ماندگاری مطمئن بشه. برای این کار بدافزار از یک اسکریپت Boot جدید، rc3.d، استفاده میکنه تا هر زمان که دستگاه ریستارت شد، اجرا بشه. بکدور در /etc/rc3.d/S93InitSystemd.sh قرار میگیره و شامل اسکریپت Bash زیر هستش:
|
1 2 3 4 5 6 7 |
trap "rm -f $iocpid" EXIT while true; do if ! pidof "iocontrol" > /dev/null; then iocontrol >/dev/null 2>&1 & fi sleep 5 done |
علاوه بر این بکدور، بدافزار با نام iocontrol در دایرکتوری /usr/bin قرار میگیره.
ارتباط با C2 از طریق MQTT:
بعد از اینکه این Hostname به آدرس IP ترجمه شد، بدافزار از دومین گزینه در پیکربندی، 8883، بعنوان پورت برای اتصال به C2 استفاده میکنه. این پورت معمولا توسط ارتباطات MQTT استفاده میشه. محققا بعد از بررسی کدها، متوجه شدن که بدافزار واقعا از MQTT استفاده میکنه.
پروتکل MQTT :
پروتکل MQTT یک پروتکل شبکه مبتنی بر انتشار و اشتراک (publish-subscribe) هستش که پیام‌ها رو بین دستگاهها منتقل میکنه. این پروتکل برای استفاده در محیط‌هایی طراحی شده که پهنای باند شبکه محدود یا غیرقابل اعتماد هستش، و به همین دلیل برای کاربردهای اینترنت اشیا (IoT) بسیار مناسب هستش. به همین دلایل، و همچنین برای مخفی‌کاری بیشتر، محققا معتقدن که مهاجمین تصمیم گرفتن از پروتکل MQTT برای ارتباطات با C2 خودشون استفاده کنن.
برای اتصال، بدافزار از MQTT 4.0 استفاده میکنه و سه شناسه مختلف رو به C2 ارسال میکنه: شناسه قربانی (Client ID)، نام کاربری و رمز عبور. برای شناسه، بدافزار از GUID ذخیره شده در حافظه خودشون استفاده میکنه، نام کاربری متغیر محیطی 3 (گرفته شده از GUID) و رمز عبور متغیر محیطی 4 (گرفته شده از GUID) هستش. با استفاده از این شناسه‌ها، بدافزار به بروکر MQTT احراز هویت میکنه.
بعد از اتصال به بروکر MQTT، بدافزار بلافاصله یک پیام “hello” بصورت زیر منتشر میکنه:
|
1 |
{GUID}/hello |
این پیام C2 رو از یک اتصال جدید مطلع میکنه و بسیاری از اطلاعات شناسایی در مورد دستگاه آلوده رو ارسال میکنه. در پیام hello، بدافزار یک JSON با این اطلاعات رو ارسال میکنه:
|
1 2 3 4 5 6 7 8 9 10 |
{ "hostname": "HOSTNAME", "current_user": "CURRENT_USER", "device_name": "DEVICE_NAME", "device_model": "DEVICE_MODEL", "timezone": "TIMEZONE", "firmware_version": "FIRMWARE_VERSION", "geo_location": "GEO_LOCATION", "version": "MALWARE_VERSION" } |
برای بدست آوردن این اطلاعات مثلا نام کاربری و hostname و … ، بدافزار از دستورات سیستم عامل استفاده میکنه. در این فرآیند، بدافزار با فراخوانی تابع dlopen با پارامتر libc.so.6 ، یک handle به کتابخونه libc اختصاص میده. بعدش با استفاده از این handle، بدافزار با استفاده از تابع dlsym و با ارسال نام تابع “system” به اون، اشاره گر به تابع سیستمی رو بدست میاره و در نهایت از این اشاره گر برای اجرای دستورات سیستم عامل مورد نیاز خودش استفاده میکنه.
برای هر دستور سیستم عامل، بدافزار دستور زیر رو می سازه:
|
1 |
OS_COMMAND > /tmp/{RANDOM_16_chars}.txt 2>&1 |
بعنوان بخشی از پیام hello ، بدافزار دستورات سیستم عاملی زیر رو به ترتیب اجرا میکنه:
|
1 2 3 4 5 |
uname -v > /tmp/{RANDOM_16_chars}.txt 2>&1 hostname > /tmp/{RANDOM_16_chars}.txt 2>&1 whoami > /tmp/{RANDOM_16_chars}.txt 2>&1 date +%Z > /tmp/{RANDOM_16_chars}.txt 2>&1 uname -r > /tmp/{RANDOM_16_chars}.txt 2>&1 |
بعد از ارسال پیام hello، بدافزار دستور زیر رو ارسال میکنه:
|
1 |
{GUID}/push |
با استفاده از این دستور، C2 دستورات اجرایی رو برای بدافزار ارسال میکنه که بدافزار اونارو در یک روتین callback اجرا میکنه که هر زمان پیام MQTT دریافت بشه، فراخوانی میشه.
دستورات پشتیبانی شده:
در این روتین، بدافزار پیام دریافتی رو تجزیه و دستور ارسال شده توسط C2 رو استخراج میکنه. هر دستور از C2 یکی از پنج نوع مختلف است که هر کدام با یک کد عملیاتی متفاوت شناسایی میشن:
| OpCode | دستور | توضیحات |
|---|---|---|
| 0 | Send hello | پیام Hello رو با یسری اطلاعات اولیه دوباره ارسال میکنه |
| 1 | Check exec | بررسی کنید که آیا بدافزار در /usr/bin/iocontrol نصب و قابل اجراست . رشته 1:1 رو منتشر کنید |
| 2 | Execute command | دستورات سیستم عامل دلخواه رو با استفاده از system call اجرا و خروجی رو منتشر کنید |
| 3 | Self-delete | اجرای بدافزار رو متوقف، باینری اصلی، ماندگاری و فایلهای لاگ مربوطه رو حذف کنید. رشته 3:1 رو منتشر کنید. |
| 8 | Port scan | یک رنج از IP رو با یک پورت مشخص اسکن میکنه. بدافزار IP شروع، پایان و یک پورت رو برای اسکن دریافت میکنه.نتیجه رو منتشر کن |
بعد از اجرای دستور، بدافزار بصورت زیر پاسخ میده:
|
1 |
{GUID}/output |
جریان اجرای ساده شده IOCONTROL :
زیرساخت IOCONTROL :
دامنه C2 این بدافزار uuokhhfsdlk[.]tylarion867mino[.]com هستش که به IP:159[.]100[.]6[.]69 متصل میشه.
دامنه:
دامنه tylarion867mino[.]com در 23 نوامبر 2023 ثبت شده. این دامنه توسط مهاجمین برای راه اندازی زیرساخت C2 و کنترل همه دستگاههای آلوده، استفاده میشده.
آدرس دامنه C2 در زمان نگارش این گزارش به 159[.]100[.]6[.]69 متصل می شد. این آدرس در آلمان میزبانی شده و سرویسهای MQTT روی پورتهای 1883 و 8883 و سرور مدیریت RabbitMQ روی پورت 15672 در حال اجرا بودن. ارتباطات با سرور C2 روی پورت 8883 میتونه هم قربانیانی باشه که به C2 گزارش میدن و هم یک اپراتور که به سرور دسترسی داره.
رکوردهای DNS قدیمی‌تر، از حدود سال 2023، نشون میده که دامنه ocferda[.]com در حال استفاده بوده و به همون آدرس IP C2 متصل می شده.