Во время очередного расследования наша команда Solar JSOC CERT наткнулась на неизвестный RAT. Но после проведения глубокого анализа стало понятно, что перед нами новая версия уже известного RAT (3.3a), который использует группировка APT31. Его первую версию эксперты по кибербезопасности описывали еще в 2021 году. За это время ВПО претерпело множество изменений и обзавелось новым функционалом. Его и разберем в статье. Дополнительно опишем особенности библиотеки wolfSSL, используемой злоумышленниками для реализации протокола TLS при взаимодействии с C2, а также возможные шаги для определения ее версии.

Для закрепления в системе и запуска RAT злоумышленники использовали службы. Схема запуска RAT, как и в прошлой версии, использует DLL Hijacking и приведена на рисунке:

 Опишем подробнее каждый этап.

Этап 1. Начальный запуск

Рассматриваемый RAT устанавливался на хосты уже после того, как злоумышленники получили доступ к учетным записями с административными правами. Так что для наделения бэкдора максимальными правами и закрепления в системе создавались службы, которые запускали легитимный переименованный файл MicrosoftEdgeUpdate.exe с правами LocalSystem.

В одной директории рядом с данным файлом всегда также располагались:

• вредоносная DLL (загрузчик) msedgeupdate.dll;

• зашифрованный RAT без конфигурации.

По результатам расследования мы собрали следующие варианты расположения и названий MicrosoftEdgeUpdate.exe:

C:\ProgramData\Microsoft\DRM\DRMs.exe

C:\ProgramData\Microsoft\DeviceSync\Data\DeviceSyncs.exe

C:\ProgramData\Microsoft\DeviceSync\DeviceSyncs.exe

C:\ProgramData\Microsoft\Crypto\Cryptos.exe

MicrosoftEdgeUpdate.exe представляет собой легитимный файл, имеющий действительную цифровую подпись Microsoft, который используется при установке и обновлении браузера Microsoft Edge. На рисунке представлены свойства файла MicrosoftEdgeUpdate.exe, переименованного в DeviceSyncs.exe:

После запуска легитимный переименованный MicrosoftEdgeUpdate.exe через LoadLibraryEx загружает вредоносную msedgeupdate.dll, которая располагается в том же каталоге.

Этап 2. Загрузчик

Вредоносная DLL msedgeupdate.dll – это неподписанная 32-разрядная библиотека, накрытая VMProtect 3.0-3.5. Дата компиляции, скорее всего, изменена вручную: 22.04.18 из FileHeader и 30.06.2021 из экспортной таблицы. Злоумышленники не старались подражать оригинальной библиотеке.

Экспортные функции

В качестве «пасхалок» злоумышленники использовали названия функций с номерами #1 и #16:

 #1 안녕하십니까 – «Всем привет» (в переводе с корейского).

#16 안녕 – «Здравствуйте» (в переводе с корейского).

Все экспортные функции не представляют интереса, так как выполняют одну процедуру, в которой выполняется четыре API-вызова:

Вредоносный код загрузчика располагается в DllEntryPoint, которая вызывается при выполнении LoadLibraryEx.

Из арсенала VMProtect использовался только модуль обфускации API-вызовов, так как после инициализации виртуальной машины выполнение переходит к DllEntryPoint в секции .text, в которой отсутствует виртуализация, но все API-вызовы обфусцированы.

Приведем высокоуровневое описание функционала загрузчика и дадим комментарии по:

1. Расшифровке RAT и записи конфига;

2. Инжекту RAT в C:\Windows\System32\dllhost.exe и его запуску.

Конфиг

Конфиг хранится в незашифрованном виде в загрузчике (во вредоносной DLL) в секции .data по RVA 0x770. Также во всех обнаруженных нами образцах совпадал raw address конфига – 0x11170:

Мы обнаружили две конфигурации с одним и тем же сервером управления, но с разными значениями других параметров:

Для удобства приводим сравнительную таблицу двух конфигураций:

Расшифровка RAT и запись конфига

Для расшифровки нагрузки используется xor с 5-байтовым ключом.

Первая часть xor-ключа хранится в виде последовательности четырёх dword:

Далее в конец к ней дописывается байт 0x0F (вторая часть xor-ключа). В цикле при выполнении операции xor используется наименее значимый байт dword. Таким образом, ключ можно представить в виде последовательности байт: 13184F290F. В первой версии RAT использовалась аналогичная схема хранения и дополнения xor-ключа.

Дополненный конфиг записывается в расшифрованную нагрузку поверх egg-строки "w4wg7x" (специальная строка-индикатор) в секции .data:

В кодировке UTF16-LE строка-индикатор выглядит так «㑷杷砷», но не переводится во что-то, имеющее смысл.

Как видно, сразу после расшифровки конфигурация RAT пустая. Далее с помощью WriteProcessMemory выполняется инжект RAT в C:\Windows\System32\dllhost.exe. Через SetThreadContext корректируется EntryPoint SUSPENDED-процесса и выполняется его запуск.

Этап 3. RAT

Ниже приведем описание структуры и функционала RAT.

Сравнение версий

Специалисты Solar JSOC CERT обнаружили две версии полезной нагрузки. Оба файла представляют собой 32-разрядные исполняемые файлы со следующими датами компиляции из Debug-секции.

Если сравнить адреса секций, то видно, что у более поздней версии все адреса секций кроме .text смещены на 0x200. Bindiff оценил индекс похожести в 94% с индексом доверия в 99%, то есть файлы практически идентичны.

Если детально сравнивать файлы, то можно обнаружить, что было добавлено в более поздней версии.

По raw-адресу 0xCС00 (0x40D800 VA) в старой версии располагается функция:

В новой версии перед этой функцией добавили ещё одну по raw-адресу 0xCC20 (0x40D820 VA):

Добавленная функция стала вызываться в функциях выполнения команд сервера управления: в функции выполнения произвольной команды с сохранением результатов и в функции remote shell, основанной на pipe’ах:

Также размер .text секции был увеличен из-за выравнивания: с raw-адреса 0x80A00 или 0x80C00 начинается секция .rdata (байты 7E 12 0A …).

Структура RAT

Рассмотрим структуру расшифрованной полезной нагрузки. Помимо самого RAT в PE-файле содержится ещё два PE-файла:

keylogger.exe – очевидно, keylogger.

ConsentUXA.dll – это вредоносная DLL для получения снимков экрана.

Расскажем про них подробнее:

keylogger.exe

Имя файла (keylogger.exe) взято из параметра Name таблицы экспортов.

keylogger.exe – вредоносный файл, представляющий собой 32-разрядную версию keylogger, который по умолчанию записывает результаты своей работы в файл под названием «䝗㡗坐» (ascii-строка WGW8PW). Если пробовать перевести данные символы, то получается что-то непонятное вроде «тигр сидит за дверной занавеской»:

䝗 – «тигр» или «свирепый и отважный солдат»;

㡗 – «дверная занавеска / перегородка», «пушистый / пернатый», вид тонкого шелка;

坐 – «сидеть».

Возможно, нет смысла переводить данные символы, так как ascii-строка WGW8PW используется RAT в качестве egg-строки.

В процессе запуска, если у RAT есть права LocalSystem, то создается отдельный поток, который каждые три минуты выполняет проверку и для каждого нового физического пользователя создает дочерний процесс, в который инжектирует keylogger. Схема инжекта аналогична вышеописанной при запуске самого RAT. Перед самим инжектом в памяти в raw-образе keylogger.exe выполняется замена egg-строки WGW8PW на полный путь до файла keylogger_output_filename из конфига RAT:

Mutex "KeyLog" используется, чтобы функционировал только один экземпляр Keylogger. При запуске создается невидимое окно c названием SetEvent, классом Twnd и процедурой, которая обрабатывает сообщения типа WM_INPUT. Далее с помощью RegisterRawInputDevices окну разрешается получать сообщения WM_INPUT и с помощью GetRawInputData получаются нажатые клавиши, которые записываются в файл в формате:

 \r\n\r\n[%02d:%02d:%02d %4d-%02d-%02d]--[USER:<имя_пользователя>]--[<заголовок_активного_окна >]\r\n<нажатые клавиши>

Перед записью данные шифруются с помощью однобайтового xor 0x7F.

ConsentUXA.dll

Имя файла (ConsentUXA.dll) взято из параметра Name таблицы экспортов.

ConsentUXA.dll – вредоносная 32-разрядная библиотека, содержащая экспортные функции #1 ScreenCapture, #2 ScreenSpy.

Дата компиляции из File Header – 20.07.2022 01:31:32 UTC.

По названиям экспортных функций и некоторым участкам кода можно предположить, что за основу был взят код модуля ScreenSpy Gh0st RAT с репозитория от 31.07.2016.

В репозитории в файле server\2015Remote\2015Remote.rc указана версия 1.0.0.1, что отличается от более старых репозиториев Gh0st RAT:

Также имеются и другие репозитории-клоны с исходными кодами Gh0st RAT версии 3.6. Здесь в качестве примера приведен один из вариантов с самым похожим исходным кодом. Возможно, этот репозиторий 2016 года (от пользователя zibility) содержит более новую версию Gh0st.

Экспортная функция #1 ScreenCapture выполняет скриншот экрана. Результаты работы выводятся в STD_OUTPUT_HANDLE. Первые 4 байта – размер, далее – данные bmp-файла.

Экспортная функция #1 ScreenSpy постоянно делает скриншоты экрана, имитируя «слежку» в реальном времени. Результаты работы также отправляются в STD_OUTPUT_HANDLE. Используется так называемое сканирование экрана, когда для сравнения выбирается его часть. Перед отправкой выполняется сравнение частей с соответствующими частями предыдущего снимка. В STD_OUTPUT_HANDLE отправляются только измененные части (здесь подробно не будем останавливаться на формате измененных частей, исходный код есть на github). Формат аналогичен: первые 4 байта – размер, далее – измененные данные bmp-файла.

Библиотека wolfSSL

Все рассмотренные образцы общались с C2 через raw-сокеты и библиотеку с открытым исходным кодом wolfSSL, реализующую функции SSL. Стоит отметить, что в строках не было никаких прямых упоминаний этой библиотеки. При анализе кода в глаза бросились специфические коды возврата:

Коды возврата ошибок в wolfSSL имеют отрицательные значения. Также мы обнаружили yara-правило от исследователя Steven Miller, которое также подтвердило использование wolfSSL.

Определение версии

При определении версии библиотеки wolfSSL мы обнаружили опечатку, которая позволила определить интервал возможных версий и понять, когда вышеупомянутое yara-правило перестаёт работать. А позже одна функция и размер структуры WOLFSSL_CTX помогли точно определиться с версией.

Опечатка связана с жестко закодированной строкой DOWNGRD, которая используется в протоколе TLS 1.3. Впервые данная строка с опечаткой появилась в релизе 3.12.0 (08.08.2017) в файле src/internal.c: https://github.com/wolfSSL/wolfssl/releases/tag/v3.12.0-stable

Вместо значения DOWNGRD было использовано значение DOGNGRD (0x47 – "G", 0x57 – "W"). Скорее всего, обычная опечатка. Ее исправили спустя 3 года в версии 4.4.0 (22.04.2020):

Во всех обнаруженных нами образцах присутствовала строка с опечаткой DOGNGRD, поэтому версия используемой библиотеки wolfSSL варьируется от 3.12.0 до 4.4.0 не включительно.

Также мы обнаружили, что в версии 4.5.0 "сигнатуры" клиента и сервера, которые используются при формировании Finished-сообщений в протоколе TLS в файле wolfssl/internal.h, слегка изменились:

В конец сигнатур добавили байт 0x00. Это изменение «ломает» вышеупомянутое yara-правило, так как базовые строки правила

 $base = "CLNTSRVRclient finished" ascii wide

$base2 = "CLNTserver finished" ascii wide

в wolfSSL версии ниже 4.4.0 выглядят по-другому:

Для детектирования wolfSSL любых версий можем порекомендовать использовать жестко закодированные последовательности md5 inner pad и md5 outer pad, которые также используются при формировании Finished-сообщений и задаются в файле wolfssl/internal.c:

Константа PAD_MD5 определена в файле wolfssl/internal.h:

PAD_MD5        = 48,       /* pad length for finished */

 Таким образом, в yara-правило можно добавить следующие базовые строки:

// md5_inner_pad

$base3 = { 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 }

// md5_outer_pad

$base4 = { 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C }

Позже мы обнаружили, что в функции wolfSSL_Init вызывается функция wc_InitRng(&globalRNG):

Так как статическая библиотека была скомпилирована с оптимизацией, мы видим вызов функции wc_InitRng, но в исходном коде в функции wolfSSL_Init вызывается wolfSSL_RAND_seed(NULL, 0), которая далее по цепочке делает вызов wc_InitRng:

wolfSSL_RAND_seed → wolfSSL_RAND_Init → wc_InitRng

Функция wolfSSL_RAND_seed стала вызываться в wolfSSL_Init, начиная с версии 4.1.0:

Таким образом, диапазон версий библиотеки wolfSSL сокращается:

4.0.0 < wolfSSL_version < 4.4.0

Для более точного определения версии мы воспользовались размером структуры WOLFSSL_CTX. Отдельно отметим, что размер структуры меняется в зависимости от различных параметров, задаваемых при компиляции библиотеки wolfSSL. Мы проводили сравнение размеров структур при использовании параметров по умолчанию для разных версий wolfSSL. Скорее всего, злоумышленники при компиляции также использовали параметры по умолчанию (смещения многих значений структуры WOLFSSL_CTX в RAT совпадали со смещениями в оригинальной библиотеке, скомпилированной с параметрами по умолчанию).

Таблица размеров структуры WOLFSSL_CTX с параметрами по умолчанию:

Размер структуры WOLFSSL_CTX в RAT – 0xF4:

В итоге из таблицы размеров делаем вывод, что в RAT с большой долей вероятности используется wolfSSL версии v4.1.0-stable (23.06.2019).

Использование в RAT

Для взаимодействия с C2 RAT использует raw-сокеты и методы библиотеки wolfSSL. В данном разделе кратко приведем основные параметры wolfSSL.

Используется TLS 1.2 и режим SSL_VERIFY_NONE, при котором RAT не будет проверять сертификат C2 при подключении:

 У RAT отсутствуют какие-либо встроенные сертификаты.

 Для работы wolfSSL последовательно вызываются все описанные в статье методы (wolfSSL_Init, wolfSSL_CTX_new, wolfSSL_new, wolfSSL_set_fd, wolfSSL_connect), кроме тех, которые связаны с сертификатами.

Для получения и отправки данных соответственно используются wolfSSL_read (в самом RAT используется кастомный метод mw_wolfSSL_readall) и wolfSSL_write.

Классы, STL, RTTI-артефакты

Все методы для взаимодействия с C2 и использования функционала wolfSSL реализованы в классе TCPSocket, который наследуется от базового класса TSocket с виртуальными методами.

Сам RAT написан на C++ и активно использует методы и контейнеры STL. Например, контейнеры и методы std::string, std::wstring, std::vector, std::list, std::shared_ptr, std::tuple, std::unique_ptr, std::ofstream, std::ifstream, std::filebuf.

Имеются RTTI-артефакты, которые содержат кастомные типы данных RAT. Пример одной полной RTTI-строки:

std::_LaunchPad<std::unique_ptr<std::tuple<void (__cdecl*) std::shared_ptr<TSocket>,NETHEAD,MByteArray*),std::shared_ptr<TSocket>,NETHEAD,MByteArray *>

Данная RTTI-информация используется в методах, которые создают std::unique_ptr, который содержит tuple из параметров для функции создания потока. Из длинной RTTI-строки выделим самый полезный фрагмент:

std::_LaunchPad<std::unique_ptr<std::tuple<void (__cdecl*)(std::shared_ptr<TSocket>,NETHEAD,MByteArray*),std::shared_ptr<TSocket>,NETHEAD,MByteArray *>

В нем видны кастомные типы NETHEAD (метаданные для C2) и MByteArray. Также при создании соответствующих структур данных в IDA всегда стоит обращать внимание на код инициализации параметров, так как контейнер tuple в различных реализациях может располагать в памяти параметры в обратном порядке, что и наблюдалось в наших образцах:

Остальные интересные RTTI-строки мы вынесли в раздел «Indicators of Compromise». Возможно, они пригодятся для сравнения при появлении новых релизов RAT. А они точно будут. По коду видны кастомные типы данных, классы, наследование, динамический полиморфизм. А по коду версии 3.3a видно, что идёт активная разработка и доработка RAT.

Функционал RAT

Ниже опишем самые интересные функции RAT, которыми обладают далеко не все представители данного класса ВПО.

Failover C2

Имеется функционал смены C2 (failover C2), который получает новый адрес C2. Срабатывает, если в конфиге задан параметр new_c2_url. А также в двух случаях:

• до основного цикла общения с C2, если в конфиге вообще не указан C2;

• в основном цикле общения с C2, если не удалось подключиться.

Через wolfSSL GET-запросом с new_c2_url загружаются данные во временный файл (имя файла генерируется с помощью функции tmpnam_s, например, %temp%\uwg.0), который затем считывается в память. После этого временный файл удаляется. Берется строка между жестко закодированными строками YTc1YzI1Y2ZmNTg4NDFj и YjVhZDI1MGUzNjJmMThkZmI. Расшифровывается сначала по алгоритму base64, затем через xor 9. Схема хранения и «дополнения» xor-ключа аналогична описанной в разделе «Расшифровка RAT и запись конфига».

В итоге получается строка следующего формата:

new_c2_URI\tnew_c2_port\tnew_operation_mode_value, где

 new_c2_URI – URI нового C2.

new_c2_port – порт для подключения к новому C2.

new_operation_mode_value – принимает значения 0, 1, 2.

 0 – создать shared_ptr<TCPSocket>.

1 – использовать существующий shared_ptr<TCPSocket>.

2 – запустить поток отстука на C2 – каждую минуту на C2 отправляется только заголовок (без блока данных), содержащий команду 0x70000019.

В конфигах проанализированных нами образцов параметр new_c2_url отсутствовал.

Authenticated Proxy

RAT может соединяться с C2 через http proxy-серверы с использованием HTTP Tunneling. Также поддерживаются прокси с аутентификацией на основе механизма GSSAPI SPNEGO. Пример одного из запросов RAT в процессе аутентификации:

CONNECT <c2_url>:<c2_port> HTTP/1.1 \r\n

User-Agent: My Service Endpoint 1.0\r\n

Host: <c2_url>\r\n

Proxy-Connection: Keep-Alive\r\n

Pragma: no-cache\r\n

Proxy-Authorization: Negotiate <base64_encoded_client_token>\r\n

Content-Length: 0\r\n\r\n

User-Agent: My Service Endpoint 1.0 был замечен в следующем репозитории: https://github.com/airfer/NtlmProxy/blob/2c83aa83f29e9f24f9efcd0c2a0e4850328d07e0/ntlm_proxy.c#L320

Возможно, какая-то его часть использовалась при разработке кода, ответственного за аутентификацию на прокси.

Взаимодействие с C2

Первым пакетом на C2 отправляется информация о системе и параметры RAT. В качестве ID клиента все так же используется MD5-хеш строки MAC-адреса и имени хоста (конкатенируются без разделителей), как было в версии 1.0. С системы собираются те же данные, которые дополняются большим количеством параметров RAT. После ожидается ответ от C2.

Сначала получается заголовок, затем, при необходимости, загружаются данные. Все пакеты (заголовок и данные) перед отправкой через wolfSSL полностью дополнительно шифруются по алгоритму RC4 с ключом 0x9CEC78BD. При получении сначала выполняется расшифровка по алгоритму RC4 с тем же ключом.

Данные, собираемые с жертвы

 Каждый параметр разделяется символом табуляции 0x9 – "\t".

Общая структура пакетов, отправляемых на C2

Структура первого пакета, отправляемого на C2 (зленым – заголовок, красным – данные):

Общая структура пакетов, получаемых от C2

Таблица выполняемых команд

Заключение

Выше мы описали загрузчик, структуру и новые возможности обновленной версии RAT, поделились подробностями библиотеки wolfSSL, которые позволяют определить ее версию, и показали особенности детектирования различных версий yara-правилами.

Мы убеждены, что новая версия RAT находится в активной разработке, так как видны значительные отличия по сравнению с версией 1.0. В новой версии многое добавлено (wolfSSL, keylogger, ScreenSpy, новые команды), но видны и «старые» приемы. Например, способ хранения xor-ключей, использование egg-строк, аналогичный алгоритм генерации id клиента и другие.

У нас недостаточно данных, чтобы утверждать, что данный RAT дорабатывался или эксплуатировался все той же группировкой APT31. Но, судя по схожести в тактиках и техниках злоумышленников, за использованием данного RAT стоят APT-группировки азиатского региона. В частности:

• схемы запуска – DLL Hijacking;

• каталоги размещения – C:\ProgramData;

• инструментарий – в рамках инцидента злоумышленники также использовали бэкдор PlugX;

• заимствование кода компонентов из Gh0st RAT;

• другие.

Indicators of compromise

Контрольные суммы приводятся в формате SHA256.

 Загрузчик вместе с соответствующей зашифрованной полезной нагрузкой RAT

 PE-файлы, встроенные в RAT

C2

api.inliines[.]com (213.183.53[.]156)

1.1. RTTI-строки

std::_LaunchPad<std::unique_ptr<std::tuple<void (__cdecl*)(std::shared_ptr<TSocket>,NETHEAD,MByteArray*),std::shared_ptr<TSocket>,NETHEAD,MByteArray *>

std::_LaunchPad<std::unique_ptr<std::tuple<void (__cdecl*)(std::shared_ptr<TSocket>),std::shared_ptr<TSocket> >

std::_LaunchPad<std::unique_ptr<std::tuple<unsigned long (__stdcall*)(void)>

std::_LaunchPad<std::unique_ptr<std::tuple<unsigned long (__stdcall*)(std::shared_ptr<TSocket>,void *),std::shared_ptr<TSocket>,void *>

std::_LaunchPad<std::unique_ptr<std::tuple<unsigned long (__stdcall*)(TSocket *,unsigned int),TSocket *,unsigned int>

std::_LaunchPad<std::unique_ptr<std::tuple<unsigned long (__stdcall*)(NETHEAD,int,char *),NETHEAD,int,char *>

std::_LaunchPad<std::unique_ptr<std::tuple<unsigned long (__stdcall*)(NETHEAD,int),NETHEAD,int>

std::_LaunchPad<std::unique_ptr<std::tuple<unsigned long (__stdcall*)(NETHEAD,__int64,std::basic_string<char,std::char_traits<char>,std::allocator<char> >),NETHEAD,__int64,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >

std::_LaunchPad<std::unique_ptr<std::tuple<unsigned long (__stdcall*)(NETHEAD),NETHEAD>

Автор: Антон Каргин, инженер технического расследования "РТК-Солар".