Форум АНТИЧАТ - RATKing: новая кампания с троянами удаленного доступа

В конце мая обнаружили кампанию распространения ВПО класса Remote Access Trojan (RAT) — программ, которые позволяют злоумышленникам удаленно управлять зараженной системой.

Рассматриваемая группировка отличилась тем, что она не выбрала для заражения какое-то определенное семейство RAT. В атаках в рамках кампании были замечены сразу несколько троянов (все в широком доступе). Этой чертой группировка напомнила о крысином короле — мифическом животном, которое состоит из грызунов с переплетенными хвостами.

https://habrastorage.org/webt/gm/q3/...xttap6hs8.jpeg

Оригинал взят из монографии К. Н. Россикова «Мыши и мышевидные грызуны, наиболее важные в хозяйственном отношении» (1908 г.)

В честь этого существа назвали рассматриваемую группировку RATKing. В этом посте мы расскажем подробно о том, как злоумышленники проводили атаку, какие инструменты они использовали, а также поделимся своими соображениями относительно атрибуции этой кампании.

Ход атаки

Все атаки в этой кампании проходили по следующему алгоритму:

Пользователь получал фишинговое письмо со ссылкой на Google Drive.
По ссылке жертва скачивала вредоносный VBS-скрипт, который прописывал DLL-библиотеку для загрузки конечного пейлоада в реестр Windows и запускал PowerShell, чтобы исполнить ее.
DLL-библиотека внедряла конечный пейлоад — собственно, один из используемых злоумышленниками RAT — в системный процесс и прописывала VBS-скрипт в автозапуск, чтобы закрепиться в зараженной машине.
Конечный пейлоад исполнялся в системном процессе и давал злоумышленнику возможность управлять зараженным компьютером.

Схематически это можно представить так:

https://habrastorage.org/webt/si/s-/...if795buvly.png

Далее мы сосредоточимся на первых трех этапах, поскольку нас интересует именно механизм доставки ВПО. Мы не станем подробно описывать механизм работы самих вредоносов. Они находятся в широком доступе — либо продаются на специализированных форумах, либо и вовсе распространяются как проекты с открытым исходным кодом, — а значит, не уникальны для группировки RATKing.

Анализ этапов атаки

Этап 1. Фишинговая рассылка

Атака начиналась с того, что жертва получала вредоносное письмо (злоумышленники использовали разные шаблоны с текстом, на скриншоте ниже приведен один из примеров). В сообщении была ссылка на легитимное хранилище drive.google.com, которая якобы вела на страницу загрузки документа в формате PDF.

https://habrastorage.org/webt/qe/bk/...s8aj_epbmi.png

Пример фишингового письма

Однако на деле загружался вовсе не PDF-документ, а VBS-скрипт.

При переходе по ссылке из письма на скриншоте выше загружался файл с именем Cargo Flight Details.vbs. В этом случае злоумышленники даже не пытались замаскировать файл под легитимный документ.

В то же время в рамках этой кампании мы обнаружили скрипт с именем Cargo Trip Detail.pdf.vbs. Он уже мог сойти за легитимный PDF, потому что по умолчанию Windows скрывает расширение файлов. Правда, в этом случае подозрение все еще могла вызвать его иконка, соответствовавшая VBS-скрипту.

На этом этапе жертва могла распознать обман: достаточно на секунду присмотреться к скачиваемым файлам. Однако в таких фишинговых кампаниях злоумышленники зачастую рассчитывают именно на невнимательного или спешащего пользователя.

Этап 2. Работа VBS-скрипта

VBS-скрипт, который пользователь мог открыть по неосторожности, прописывал DLL-библиотеку в реестр Windows. Скрипт был обфусцирован: строки в нем записаны в виде байтов, разделенных произвольным символом.

https://habrastorage.org/webt/ol/jr/...mtoxtplj30.png

Пример обфусцированного скрипта

Алгоритм деобфускации достаточно прост: из обфусцированной строки исключался каждый третий символ, после чего результат декодировался из 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.

https://habrastorage.org/webt/mv/ry/...rbvzaeh7ik.png

Строка с обфусцированным DLL

Каждая функция в VBS-скрипте выполнялась по мере деобфускации строк.

После запуска скрипта вызывалась функция wscript.sleep — с ее помощью выполнялось отложенное исполнение.

Далее скрипт работал с реестром Windows. Он использовал для этого технологию WMI. С ее помощью создавался уникальный ключ, и в его параметр записывалось тело исполняемого файла. Обращение к реестру через WMI выполнялось с помощью следующей команды:

GetObject(winmgmts {impersonationLevel=impersonate}!\\.\root\default: StdRegProv)

https://habrastorage.org/webt/cd/wj/...-acr5vicrc.png

Запись, сделанная в реестре 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-библиотеки

В декомпилированном виде загрузчик выглядел так:

https://habrastorage.org/webt/rx/4z/...xjqbskyjqa.png

Загрузчик в декомпилированном виде (красным подчеркнута функция, с которой начиналось исполнение DLL-библиотеки)

Загрузчик защищен протектором .Net Reactor. Со снятием данного протектора отлично справляется утилита de4dot.

Данный загрузчик:

осуществлял инжект пейлоада в системный процесс (в данном примере это svchost.exe);
прописывал VBS-скрипт в автозапуск.

Инжект пейлоада

Рассмотрим функцию, которую вызывал PowerShell-скрипт.

https://habrastorage.org/webt/li/p5/...49nlrcc5nc.png

Функция, вызываемая 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;

https://habrastorage.org/webt/zs/go/...dwxyyoka6o.png

Начало процесса инжекта

записывал содержимое пейлоада в адресное пространство процесса svchost.exe при помощи функции WriteProcessMemory (как на скриншоте ниже);

возобновлял процесс svchost.exe при помощи функции ResumeThread.

https://habrastorage.org/webt/hf/qe/...zam_f8n-a0.png

Завершение процесса инжекта

Загружаемое ВПО

В результате описанных действий в зараженной системе устанавливалась одна из нескольких вредоносных программ класса 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.

Источник:https://habr.com/ru/company/bizone/blog/508324/