В конце мая обнаружили кампанию распространения ВПО класса Remote Access Trojan (RAT) — программ, которые позволяют злоумышленникам удаленно управлять зараженной системой. Рассматриваемая группировка отличилась тем, что она не выбрала для заражения какое-то определенное семейство RAT. В атаках в рамках кампании были замечены сразу несколько троянов (все в широком доступе). Этой чертой группировка напомнила о крысином короле — мифическом животном, которое состоит из грызунов с переплетенными хвостами. Оригинал взят из монографии К. Н. Россикова «Мыши и мышевидные грызуны, наиболее важные в хозяйственном отношении» (1908 г.) В честь этого существа назвали рассматриваемую группировку RATKing. В этом посте мы расскажем подробно о том, как злоумышленники проводили атаку, какие инструменты они использовали, а также поделимся своими соображениями относительно атрибуции этой кампании. Ход атаки Все атаки в этой кампании проходили по следующему алгоритму: Пользователь получал фишинговое письмо со ссылкой на Google Drive. По ссылке жертва скачивала вредоносный VBS-скрипт, который прописывал DLL-библиотеку для загрузки конечного пейлоада в реестр Windows и запускал PowerShell, чтобы исполнить ее. DLL-библиотека внедряла конечный пейлоад — собственно, один из используемых злоумышленниками RAT — в системный процесс и прописывала VBS-скрипт в автозапуск, чтобы закрепиться в зараженной машине. Конечный пейлоад исполнялся в системном процессе и давал злоумышленнику возможность управлять зараженным компьютером. Схематически это можно представить так: Далее мы сосредоточимся на первых трех этапах, поскольку нас интересует именно механизм доставки ВПО. Мы не станем подробно описывать механизм работы самих вредоносов. Они находятся в широком доступе — либо продаются на специализированных форумах, либо и вовсе распространяются как проекты с открытым исходным кодом, — а значит, не уникальны для группировки RATKing. Анализ этапов атаки Этап 1. Фишинговая рассылка Атака начиналась с того, что жертва получала вредоносное письмо (злоумышленники использовали разные шаблоны с текстом, на скриншоте ниже приведен один из примеров). В сообщении была ссылка на легитимное хранилище drive.google.com, которая якобы вела на страницу загрузки документа в формате PDF. Пример фишингового письма Однако на деле загружался вовсе не PDF-документ, а VBS-скрипт. При переходе по ссылке из письма на скриншоте выше загружался файл с именем Cargo Flight Details.vbs. В этом случае злоумышленники даже не пытались замаскировать файл под легитимный документ. В то же время в рамках этой кампании мы обнаружили скрипт с именем Cargo Trip Detail.pdf.vbs. Он уже мог сойти за легитимный PDF, потому что по умолчанию Windows скрывает расширение файлов. Правда, в этом случае подозрение все еще могла вызвать его иконка, соответствовавшая VBS-скрипту. На этом этапе жертва могла распознать обман: достаточно на секунду присмотреться к скачиваемым файлам. Однако в таких фишинговых кампаниях злоумышленники зачастую рассчитывают именно на невнимательного или спешащего пользователя. Этап 2. Работа VBS-скрипта VBS-скрипт, который пользователь мог открыть по неосторожности, прописывал DLL-библиотеку в реестр Windows. Скрипт был обфусцирован: строки в нем записаны в виде байтов, разделенных произвольным символом. Пример обфусцированного скрипта Алгоритм деобфускации достаточно прост: из обфусцированной строки исключался каждый третий символ, после чего результат декодировался из base16 в исходную строку. Например, из значения 57Q53s63t72s69J70r74e2El53v68m65j6CH6Ct (выделено на скриншоте выше) получалась строка WScript.Shell. Для деобфускации строк мы использовали функцию на Python: def decode_str(data_enc): return binascii.unhexlify(''.join([data_enc[i:i+2] for i in range(0, len(data_enc), 3)])) Ниже на строках 9–10 выделено значение, при деобфускации которого получался DLL-файл. Именно он запускался на следующем этапе с помощью PowerShell. Строка с обфусцированным DLL Каждая функция в VBS-скрипте выполнялась по мере деобфускации строк. После запуска скрипта вызывалась функция wscript.sleep — с ее помощью выполнялось отложенное исполнение. Далее скрипт работал с реестром Windows. Он использовал для этого технологию WMI. С ее помощью создавался уникальный ключ, и в его параметр записывалось тело исполняемого файла. Обращение к реестру через WMI выполнялось с помощью следующей команды: GetObject(winmgmts {impersonationLevel=impersonate}!\\.\root\default:StdRegProv) Запись, сделанная в реестре VBS-скриптом Этап 3. Работа DLL-библиотеки На третьем этапе вредоносная DLL-библиотека загружала конечный пейлоад, внедряла его в системный процесс и обеспечивала автозапуск VBS-скрипта при входе пользователя в систему. Запуск через PowerShell DLL-библиотека исполнялась с помощью следующей команды в PowerShell: [System.Threading.Thread]::GetDomain().Load((ItemProperty HKCU:\/\/\/Software\/\/\/<rnd_sub_key_name> ).<rnd_value_name>); [GUyyvmzVhebFCw]::EhwwK('WScript.ScriptFullName', 'rWZlgEtiZr', 'WScript.ScriptName'),0 Эта команда делала следующее: получала данные значения реестра с именем rnd_value_name — эти данные представляли собой DLL-файл, написанный на платформе .Net; загружала полученный .Net-модуль в память процесса powershell.exe с помощью функции [System.Threading.Thread]::GetDomain().Load() (подробное описание функции Load() доступно на сайте Microsoft); исполняла функцию GUyyvmzVhebFCw]::EhwwK() — с нее начиналось исполнение DLL‑библиотеки — с параметрами vbsScriptPath, xorKey, vbsScriptName. Параметр xorKey хранил ключ для расшифровки конечного пейлоада, а параметры vbsScriptPath и vbsScriptName передавались для того, чтобы прописать VBS-скрипт в автозапуск. Описание DLL-библиотеки В декомпилированном виде загрузчик выглядел так: Загрузчик в декомпилированном виде (красным подчеркнута функция, с которой начиналось исполнение DLL-библиотеки) Загрузчик защищен протектором .Net Reactor. Со снятием данного протектора отлично справляется утилита de4dot. Данный загрузчик: осуществлял инжект пейлоада в системный процесс (в данном примере это svchost.exe); прописывал VBS-скрипт в автозапуск. Инжект пейлоада Рассмотрим функцию, которую вызывал PowerShell-скрипт. Функция, вызываемая PowerShell-скриптом Данная функция осуществляла следующие действия: расшифровывала два массива данных (array и array2 на скриншоте). Первоначально они были сжаты с помощью gzip и зашифрованы алгоритмом XOR с ключом xorKey; копировала данные в выделенные области памяти. Данные из array — в область памяти, на которую указывал intPtr (payload pointer на скриншоте); данные из array2 — в область памяти, на которую указывал intPtr2 (shellcode pointer на скриншоте); вызывала функцию CallWindowProcA (описание этой функции есть на сайте Microsoft) со следующими параметрами (ниже перечислены имена параметров, на скриншоте они идут в том же порядке, но с рабочими значениями): lpPrevWndFunc — указатель на данные из array2; hWnd — указатель на строку, содержащую путь к исполняемому файлу svchost.exe; Msg — указатель на данные из array; wParam, lParam — параметры сообщения (в данном случае эти параметры не использовались и имели значения 0); создавала файл %AppData%\Microsoft\Windows\Start Menu\Programs\Startup\<name>.url, где <name> — это первые 4 символа параметра vbsScriptName (на скриншоте фрагмент кода с этим действием начинается с команды File.Copy). Таким образом вредонос добавлял URL-файл в список файлов для автозапуска при входе пользователя в систему и тем самым закреплялся на зараженном компьютере. URL-файл содержал ссылку на скрипт: [InternetShortcut] URL = file : ///<vbsScriptPath> Для понимания того, как осуществлялся инжект, мы расшифровали массивы данных array и array2. Для этого мы использовали следующую функцию на Python: def decrypt(data, key): return gzip.decompress( bytearray([data ^ key[i % len(key)] for i in range(len(data))])[4:]) В результате мы выяснили, что: array представлял собой PE-файл — это и есть конечный пейлоад; array2 представлял собой шелл-код, необходимый для осуществления инжекта. Шелл-код из массива array2 передавался в качестве значения функции lpPrevWndFunc в функцию CallWindowProcA. lpPrevWndFunc — функция обратного вызова, ее прототип выглядит так: LRESULT WndFunc( HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam ); Таким образом, при запуске функции CallWindowProcA с параметрами hWnd, Msg, wParam, lParam исполняется шелл-код из массива array2 с аргументами hWnd и Msg. hWnd — это указатель на строку, содержащую путь к исполняемому файлу svchost.exe, а Msg — указатель на конечный пейлоад. Шелл-код получал адреса функций из kernel32.dll и ntdll32.dll по значениям хешей от их имен и выполнял инжект конечного пейлоада в память процесса svchost.exe, используя технику Process Hollowing (подробно о ней можно прочитать в этой статье). При инжекте шелл-код: создавал процесс svchost.exe в приостановленном состоянии при помощи функции CreateProcessW; затем скрывал отображение секции в адресном пространстве процесса svchost.exe при помощи функции NtUnmapViewOfSection. Таким образом программа освобождала память оригинального процесса svchost.exe, чтобы затем по этому адресу выделить память для пейлоада; выделял память для пейлоада в адресном пространстве процесса svchost.exe при помощи функции VirtualAllocEx; Начало процесса инжекта записывал содержимое пейлоада в адресное пространство процесса svchost.exe при помощи функции WriteProcessMemory (как на скриншоте ниже); возобновлял процесс svchost.exe при помощи функции ResumeThread. Завершение процесса инжекта Загружаемое ВПО В результате описанных действий в зараженной системе устанавливалась одна из нескольких вредоносных программ класса RAT. В таблице ниже перечислены использованные в атаке вредоносы, которые мы с уверенностью можем приписать одной группе злоумышленников, поскольку семплы обращались к одному и тому же серверу управления. Название ВПО Впервые замечено SHA-256 C&C Процесс, в который осуществляется инжект Darktrack 16-04-2020 ea64fe672c953adc19553ea3b9118ce4ee88a14d92fc7e75aa04972848472702 kimjoy007.dyndns[.]org:2017 svchost Parallax 24-04-2020 b4ecd8dbbceaadd482f1b23b712bcddc5464bccaac11fe78ea5fd0ba932a4043 kimjoy007.dyndns[.]org:2019 svchost WARZONE 18-05-2020 3786324ce3f8c1ea3784e5389f84234f81828658b22b8a502b7d48866f5aa3d3 kimjoy007.dyndns[.]org:9933 svchost Netwire 20-05-2020 6dac218f741b022f5cad3b5ee01dbda80693f7045b42a0c70335d8a729002f2d kimjoy007.dyndns[.]org:2000 svchost Примеры распространяемого ВПО с одним и тем же сервером управления Здесь примечательны две вещи. Во-первых, сам факт, что злоумышленники использовали сразу несколько различных семейств RAT. Такое поведение не характерно для известных кибергруппировок, которые зачастую используют приблизительно одинаковый набор привычных для них инструментов. Во-вторых, RATKing использовали вредоносы, которые либо продаются на специализированных форумах за небольшую цену, либо и вовсе являются проектами с открытым исходным кодом. Более полный перечень использованного в кампании ВПО — с одной важной оговоркой — приведен в конце статьи. О группировке Мы не можем отнести описанную вредоносную кампанию к каким-либо известным злоумышленникам. Пока мы считаем, что эти атаки совершила принципиально новая группировка. Как мы уже писали в начале, мы назвали ее RATKing. Источник:https://habr.com/ru/company/bizone/blog/508324/