В конце мая обнаружили кампанию распространения ВПО класса 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\/\/\/ ).);
[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\.url, где — это первые 4 символа параметра vbsScriptName (на скриншоте фрагмент кода с этим действием начинается с команды File.Copy). Таким образом вредонос добавлял URL-файл в список файлов для автозапуска при входе пользователя в систему и тем самым закреплялся на зараженном компьютере. URL-файл содержал ссылку на скрипт:
[InternetShortcut]
URL = file : ///
Для понимания того, как осуществлялся инжект, мы расшифровали массивы данных 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
ea64fe672c953adc19553ea3b9118ce4ee88a14d92fc7e75aa 04972848472702
kimjoy007.dyndns[.]org:2017
svchost
Parallax
24-04-2020
b4ecd8dbbceaadd482f1b23b712bcddc5464bccaac11fe78ea 5fd0ba932a4043
kimjoy007.dyndns[.]org:2019
svchost
WARZONE
18-05-2020
3786324ce3f8c1ea3784e5389f84234f81828658b22b8a502b 7d48866f5aa3d3
kimjoy007.dyndns[.]org:9933
svchost
Netwire
20-05-2020
6dac218f741b022f5cad3b5ee01dbda80693f7045b42a0c703 35d8a729002f2d
kimjoy007.dyndns[.]org:2000
svchost
Примеры распространяемого ВПО с одним и тем же сервером управления
Здесь примечательны две вещи.
Во-первых, сам факт, что злоумышленники использовали сразу несколько различных семейств RAT. Такое поведение не характерно для известных кибергруппировок, которые зачастую используют приблизительно одинаковый набор привычных для них инструментов.
Во-вторых, RATKing использовали вредоносы, которые либо продаются на специализированных форумах за небольшую цену, либо и вовсе являются проектами с открытым исходным кодом.
Более полный перечень использованного в кампании ВПО — с одной важной оговоркой — приведен в конце статьи.
О группировке
Мы не можем отнести описанную вредоносную кампанию к каким-либо известным злоумышленникам. Пока мы считаем, что эти атаки совершила принципиально новая группировка. Как мы уже писали в начале, мы назвали ее RATKing.
Древовидный вид