RATKing: новая кампания с троянами удаленного доступа
В конце мая мы обнаружили кампанию распространения ВПО класса 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 выполнялось с помощью следующей команды:
На третьем этапе вредоносная DLL-библиотека загружала конечный пейлоад, внедряла его в системный процесс и обеспечивала автозапуск VBS-скрипта при входе пользователя в систему.
Запуск через PowerShell
DLL-библиотека исполнялась с помощью следующей команды в PowerShell:
получала данные значения реестра с именем 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%MicrosoftWindowsStart MenuProgramsStartup<name>.urlкайда <name> — это первые 4 символа параметра vbsScriptName (на скриншоте фрагмент кода с этим действием начинается с команды File.Copy). Таким образом вредонос добавлял URL-файл в список файлов для автозапуска при входе пользователя в систему и тем самым закреплялся на зараженном компьютере. URL-файл содержал ссылку на скрипт:
Для понимания того, как осуществлялся инжект, мы расшифровали массивы данных array и array2. Для этого мы использовали следующую функцию на Python:
def decrypt(data, key):
return gzip.decompress(
bytearray([data[i] ^ key[i % len(key)] for i in range(len(data))])[4:])
В результате мы выяснили, что:
array представлял собой PE-файл — это и есть конечный пейлоад;
array2 представлял собой шелл-код, необходимый для осуществления инжекта.
Шелл-код из массива array2 передавался в качестве значения функции lpPrevWndFunc в функцию CallWindowProcA. lpPrevWndFunc — функция обратного вызова, ее прототип выглядит так:
Таким образом, при запуске функции 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. В таблице ниже перечислены использованные в атаке вредоносы, которые мы с уверенностью можем приписать одной группе злоумышленников, поскольку семплы обращались к одному и тому же серверу управления.
Примеры распространяемого ВПО с одним и тем же сервером управления
Здесь примечательны две вещи.
Во-первых, сам факт, что злоумышленники использовали сразу несколько различных семейств RAT. Такое поведение не характерно для известных кибергруппировок, которые зачастую используют приблизительно одинаковый набор привычных для них инструментов.
Во-вторых, RATKing использовали вредоносы, которые либо продаются на специализированных форумах за небольшую цену, либо и вовсе являются проектами с открытым исходным кодом.
Более полный перечень использованного в кампании ВПО — с одной важной оговоркой — приведен в конце статьи.
О группировке
Мы не можем отнести описанную вредоносную кампанию к каким-либо известным злоумышленникам. Пока мы считаем, что эти атаки совершила принципиально новая группировка. Как мы уже писали в начале, мы назвали ее RATKing.
Для создания VBS-скрипта группировка, вероятно, использовала инструмент, похожий на утилиту VBS-Crypter от разработчика NYAN-x-CAT. На это указывает схожесть скрипта, который создает эта программа, со скриптом злоумышленников. В частности, они оба:
осуществляют отложенное исполнение с помощью функции Sleep;
используют WMI;
прописывают тело исполняемого файла в качестве параметра ключа реестра;
исполняют этот файл при помощи PowerShell в его же адресном пространстве.
Для наглядности сравните команду PowerShell для запуска файла из реестра, которую использует скрипт, созданный с помощью VBS-Crypter:
Заметим, что в качестве одного из пейлоадов злоумышленники использовали другую утилиту от NYAN-x-CAT — LimeRAT.
Адреса C&C-серверов указывают на еще одну отличительную черту RATKing: группировка предпочитает сервисы динамического DNS (см. перечень C&C в таблице с IoC).
IoC
В таблице ниже приведен полный перечень VBS-скриптов, которые с большой вероятностью можно отнести к описанной кампании. Все эти скрипты похожи и осуществляют примерно одинаковую последовательность действий. Все они инжектят ВПО класса RAT в доверенный процесс Windows. У всех них адреса C&C зарегистрированы с использованием Dynamic DNS-сервисов.
Тем не менее, мы не можем утверждать, что все эти скрипты распространялись одними и теми же злоумышленниками, за исключением семплов с одинаковыми адресами C&C (например, kimjoy007.dyndns.org).