Новости из Блогов RATKing: новая кампания с троянами удаленного доступа

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

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


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

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

Ход атаки

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

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

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



Далее мы сосредоточимся на первых трех этапах, поскольку нас интересует именно механизм доставки ВПО. Мы не станем подробно описывать механизм работы самих вредоносов. Они находятся в широком доступе — либо продаются на специализированных форумах, либо и вовсе распространяются как проекты с открытым исходным кодом, — а значит, не уникальны для группировки 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/​

 

Великолепно Ватсон !

 

Все комментарии и претензии к автору статьи, я её сюда просто скопипастил, чтобы было