Ворок: общая картина

Исследователи ESET недавно обнаружили целевые атаки с использованием незадокументированных инструментов на различные известные компании и местные органы власти, в основном в Азии. Эти атаки проводились ранее неизвестной шпионской группой, которую мы назвали Worok и которая была активна как минимум с 2020 года. Набор инструментов Worok включает загрузчик C++ CLRLoad, бэкдор PowerShell PowHeartBeat и загрузчик C# PNGLoad, который использует стеганографию для извлечения скрытых вредоносных программ. полезные нагрузки из файлов PNG.

Кто такой Ворок?

Во время ProxyShell (CVE-2021-34523) раскрытия уязвимости в начале 2021 года мы наблюдали активность различных групп APT. Один показал характеристики, общие с TA428:

• Время активности
• Целевые вертикали
• Использование ShadowPad

В остальном набор инструментов сильно отличается: например, TA428 принимал участие в Компрометация рабочего стола в 2020 году. Мы считаем, что связи недостаточно сильны, чтобы рассматривать Worok как ту же группу, что и TA428, но эти две группы могут иметь общие инструменты и общие интересы. Мы решили создать кластер и назвали его Workok. Имя было выбрано после мьютекса в загрузчике, используемом группой. Дальнейшая работа с вариантами тех же инструментов была затем связана с этой группой. Согласно телеметрии ESET, Workok был активен с конца 2020 года и продолжает оставаться активным на момент написания этой статьи.

Еще в конце 2020 года Workok был нацелен на правительства и компании в нескольких странах, в частности:

• Телекоммуникационная компания в Восточной Азии
• Банк в Средней Азии
• Компания морской отрасли в Юго-Восточной Азии
• Государственное учреждение на Ближнем Востоке
• Частная компания на юге Африки

С 2021-05 по 2022-01 наблюдался значительный перерыв в наблюдаемых операциях, но в 2022-02 XNUMX-XNUMX возобновилась активность рабочих, нацеленных на:

• Энергетическая компания в Центральной Азии
• Предприятие государственного сектора в Юго-Восточной Азии

На рис. 1 представлена ​​визуальная тепловая карта целевых регионов и вертикалей.

Учитывая профили целей и инструменты, которые мы видели развернутыми против этих жертв, мы думаем, что главная цель Ворока — украсть информацию.

Технический анализ

Хотя большинство первоначальных обращений неизвестны, в некоторых случаях до 2021 и 2022 годов мы видели эксплойты, используемые против уязвимостей ProxyShell. В таких случаях веб-оболочки обычно загружаются после использования этих уязвимостей, чтобы обеспечить постоянство в сети жертвы. Затем операторы использовали различные имплантаты, чтобы получить дополнительные возможности.

Как только доступ был получен, операторы развернули несколько общедоступных инструментов для разведки, в том числе Mimikatz, земляной червь, РеГеорги НБТскан, а затем развернули свои пользовательские имплантаты: загрузчик первого этапа, за которым последовал загрузчик .NET второго этапа (PNGLoad). К сожалению, нам не удалось получить какие-либо окончательные полезные данные. В 2021 году загрузчиком первого этапа была сборка CLR (CLRLoad), а в 2022 году она была заменена, в большинстве случаев, полнофункциональным бэкдором PowerShell (PowHeartBeat) — обе цепочки выполнения изображены на рисунке 2. Эти три инструменты подробно описаны в следующих подразделах.

Рисунок 2. Цепочки компромиссов Workok

CLRLoad: загрузчик сборки CLR

CLRLoad — это универсальная среда предустановки Windows, которую мы видели как в 32-разрядной, так и в 64-разрядной версиях. Это загрузчик, написанный на C++, который загружает следующую стадию (PNGLoad), которая должна быть Сборка общеязыковой среды выполнения (CLR) DLL-файл. Этот код загружается из файла, расположенного на диске в законном каталоге, предположительно для того, чтобы ввести в заблуждение жертв или спасателей, заставив их думать, что это законное программное обеспечение.

Некоторые примеры CLRLoad начинаются с декодирования полного пути к файлу, содержимое которого они будут загружать на следующем этапе. Эти пути к файлам кодируются однобайтовым XOR с разными ключами в каждом образце. В декодированном или открытом тексте эти пути к файлам являются абсолютными, и мы столкнулись со следующими:

• C:Program FilesVMwareVMware ToolsVMware VGAuthxsec_1_5.dll
• C:Программные файлыUltraViewermsvbvm80.dll
• C:Программные файлыInternet ExplorerJsprofile.dll
• C:Program FilesWinRarRarExtMgt.dll
• C:Program Files (x86)Программное обеспечение FoxitFoxit Readerlucenelib.dll

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

Затем CLRLoad загружает сборку CLR из возможно декодированного пути к файлу. В качестве неуправляемого кода CLRLoad достигает этого с помощью CorBindToRuntimeEx Вызовы Windows API в 32-разрядных вариантах или CLRCreateInstance вызовы в 64-битных вариантах.

PowHeartBeat: бэкдор PowerShell

PowHeartBeat — это полнофункциональный бэкдор, написанный на PowerShell, запутанный с использованием различных методов, таких как сжатие, кодирование и шифрование. Основываясь на телеметрии ESET, мы считаем, что PowHeartBeat заменил CLRLoad в более поздних кампаниях Workok в качестве инструмента, используемого для запуска PNGLoad.

Первый уровень кода бэкдора состоит из нескольких фрагментов кода PowerShell в кодировке base64. После восстановления полезной нагрузки она выполняется через IEX. После декодирования выполняется еще один слой запутанного кода, который мы можем видеть на рисунке 3.

Рисунок 3. Фрагмент декодированной основной функции второго слоя PowHeartBeat

Второй слой бэкдора сначала base64 декодирует следующий слой своего кода, который затем расшифровывается с помощью Тройной DES (режим СВС). После расшифровки этот код распаковывается с помощью GZIP алгоритм, тем самым давая третий слой кода PowerShell, который и является фактическим бэкдором. Он разделен на две основные части: конфигурация и обработка команд бэкдора.

Основной слой кода бэкдора также написан на PowerShell и использует HTTP или ICMP для связи с C&C-сервером. Он работает так, как показано на рисунке 4.

Рисунок 4. Функционирование PowHeartBeat

Конфигурация

Конфигурация содержит несколько полей, включая номер версии, необязательную конфигурацию прокси и адрес C&C. Таблица 1 описывает значения полей конфигурации в различных версиях, которые мы наблюдали.

Таблица 1. Значения полей конфигурации

На рис. 5 показан пример конфигурации, извлеченной из образца PowHeartBeat (SHA-1: 757ABA12D04FD1167528FDD107A441D11CD8C427).

Рисунок 5. Пример конфигурации

Шифрование данных

PowHeartBeat шифрует журналы и дополнительное содержимое файла конфигурации.

Содержимое файла журнала шифруется с помощью многобайтового XOR с ключом, указанным в образце открытым текстом. Интересно, ID клиента используется как соль для индекса в массиве ключей. Ключ представляет собой 256-байтовый массив, который был идентичен во всех образцах, с которыми мы сталкивались. Содержимое дополнительного конфигурационного файла шифруется многобайтовым XOR со значением из Секретный ключ как его ключ.

Коммуникации C&C

PowHeartBeat использовал HTTP для связи C&C до версии 2.4, а затем переключился на ICMP. В обоих случаях связь не шифруется.

HTTP

В бесконечном цикле бэкдор отправляет GET-запрос на C&C-сервер, запрашивая команду для выполнения. Зашифрованный ответ расшифровывается бэкдором, который обрабатывает команду и записывает вывод команды в файл, содержимое которого затем отправляется на C&C-сервер через POST-запрос.

Формат GET-запросов следующий:

Обратите внимание, что запрос создается с использованием одноименных полей конфигурации.

В ответе от C&C-сервера третий байт содержимого — это идентификатор команды, указывающий, какая команда должна быть обработана бэкдором. Мы назовем это идентификатор_команды. Оставшееся содержимое ответа будет передано в качестве аргумента обрабатываемой команде. Это содержимое шифруется с помощью алгоритма, показанного на рисунке 6. идентификатор задачи значение файла cookie, названного в честь CookieTaskIdзначение из конфигурации.

Рисунок 6. Алгоритм шифрования данных контента Requests

Ответ от C&C-сервера также содержит еще один файл cookie, имя которого задается параметром бэкдора. CookieTerminalId переменная конфигурации. Значение этого файла cookie повторяется в POST-запросе от бэкдора и не должно быть пустым. После выполнения команды бэкдора PowHeartBeat отправляет результат в виде POST-запроса на C&C-сервер. Результат отправляется в виде файла с именем .png.

ICMP

Начиная с версии 2.4 PowHeartBeat, HTTP был заменен на ICMP, отправлял пакеты с тайм-аутом в шесть секунд и нефрагментированный. Связь через ICMP, скорее всего, является способом избежать обнаружения.

В версиях 2.4 и более поздних нет серьезных изменений, но мы заметили некоторые изменения в коде:

• PowHeartBeat отправляет пакет пульса в каждом цикле, содержащем строку АБВГДЕЖЗИКЛМНОПРСТУФХЧШЭЮЯ, прежде чем запрашивать команду. Это информирует C&C сервер о том, что бэкдор готов к приему команд.
• Запросы на получение команд, выполняемых бэкдором, содержат строку abcdefghijklmnop.

Пакеты Heartbeat имеют формат, описанный на рисунке 7.

Рисунок 7. Структура пакета Heartbeat

Разница между ID клиента и флаг клиента является то, что ID клиента отличается в каждом образце, тогда как флаг клиента одинакова во всех образцах, использующих ICMP. флаг сердцебиения указывает на то, что бэкдор посылает пульс. Ответ от C&C-сервера имеет формат, показанный на рисунке 8.

Рис. 8. Схема ответа C&C-сервера

флажок здесь указывает, есть ли команда для бэкдора. Запросы на получение команд имеют формат, описанный на рисунке 9.

Рисунок 9. Схема запросов на получение команд

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

Рисунок 10. Схема ответов на запросы на получение команд

Как и в ответах HTTP, идентификатором команды является третий байт данным.

После семи последовательных ICMP-ответов с пустым или непоследовательно отформатированным содержимым передача между бэкдором и командным сервером считается завершенной.

Что касается запросов на отправку результата выполненной команды на C&C-сервер, режим сервера изменен на почтовый режим, а окончательная строка (abcdefghijklmnop) изменяется для данных результата.

Команды бэкдора

PowHeartBeat имеет различные возможности, включая выполнение команд/процессов и манипулирование файлами. В таблице 2 перечислены все команды, поддерживаемые различными проанализированными образцами.

Табл. 2. Описание команд PowHeartBeat

В случае ошибок на стороне бэкдора, бэкдор использует специальный идентификатор команды 0x00 в POST-запросе к C&C-серверу, указывая тем самым на возникновение ошибки.

Обратите внимание, что перед отправкой информации обратно на C&C-сервер данные сжимаются gzip.

PNGLoad: стеганографический загрузчик

PNGLoad — это полезная нагрузка второго этапа, развернутая Worok на скомпрометированных системах и, согласно телеметрии ESET, загружаемая либо с помощью CLRLoad, либо с помощью PowHeartBeat. Хотя мы не видим в PowHeartBeat никакого кода, который напрямую загружает PNGLoad, бэкдор имеет возможность загружать и выполнять дополнительные полезные нагрузки с C&C-сервера, что, вероятно, является тем, как злоумышленники развернули PNGLoad на системах, скомпрометированных с помощью PowHeartBeat. PNGLoad — это загрузчик, который использует байты из файлов PNG для создания полезной нагрузки для выполнения. Это 64-битный исполняемый файл .NET, запутанный .NET-реактор — которое маскируется под законное программное обеспечение. Например, на рис. 11 показаны заголовки CLR образца, маскирующегося под WinRAR DLL.

Рис. 11. Пример фальшивой DLL WinRAR

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

Рисунок 12. . Png список файлов

Каждый . Png файл, найденный этим поиском основной путь затем проверяется на наличие стеганографически встроенного контента. Во-первых, наименее значимый бит значений R (красный), G (зеленый), B (синий) и A (альфа) каждого пикселя извлекается и собирается в буфер. Если первые восемь байтов этого буфера совпадают с магическим числом, показанным на рис. 13, а следующее восьмибайтовое значение, control, не равно нулю, файл проходит стеганографическую проверку содержимого PNGLoad. Для таких файлов обработка продолжается с расшифровкой остатка буфера с помощью многобайтового исключающего ИЛИ с использованием ключа, хранящегося в файле PNGLoad. SecretKeyBytes атрибут, а затем расшифрованный буфер распаковывается с помощью gzip. Ожидается, что результатом будет сценарий PowerShell, который будет запущен немедленно.

Рис. 13. Формат буфера, который PNGLoad создает при обработке . Png файлов

Интересно, что операции, выполняемые PNGLoad, регистрируются в файле, путь которого хранится в переменной Путь к файлу журнала. Операции регистрируются только в том случае, если присутствует файл, путь которого указан внутренней переменной Путь к файлу журнала.

Нам не удалось получить образец . Png используется вместе с PNGLoad, но способ работы PNGLoad предполагает, что он должен работать с допустимыми файлами PNG. Чтобы скрыть вредоносную полезную нагрузку, Worok использует объекты Bitmap в C#, которые берут только информацию о пикселях из файлов, а не метаданные файлов. Это означает, что Worok может скрывать свою вредоносную полезную нагрузку в действительных, безобидных на вид изображениях PNG и, таким образом, скрываться на виду.

Заключение

Worok — это группа кибершпионажа, которая разрабатывает собственные инструменты, а также использует существующие инструменты для компрометации своих целей. Кража информации у своих жертв — это то, что, по нашему мнению, преследуют операторы, потому что они сосредоточены на известных организациях в Азии и Африке, нацеленных на различные секторы, как частные, так и государственные, но с особым акцентом на государственные структуры. Время активности и набор инструментов указывают на возможную связь с TA428, но мы делаем эту оценку с низкой достоверностью. Их собственный набор инструментов включает два загрузчика — один на C++ и один на C# .NET — и один бэкдор PowerShell. Хотя наша видимость ограничена, мы надеемся, что проливая свет на эту группу, мы побудим других исследователей поделиться информацией об этой группе.

МНК

Файлы

Пути файлов

Некоторые из основной путь, Путь к файлу журнала и Путь к файлу журнала значения, с которыми мы столкнулись в примерах PNGLoad:

Cеть

Мьютексы

В примерах CLRLoad имена мьютексов, с которыми мы столкнулись, следующие:

AB82UduGX0EX
ad8TbUIZl5Ga
Mr2PJVxbIBD4
oERiQtKLgPgK
U37uxsCsA4Xm
Wo0r0KGWhYGO
xBUjQR2vxYTz
zYCLBWekRX3t
3c3401ad-e77d-4142-8db5-8eb5483d7e41
9xvzMsaWqxMy

Полный список индикаторов компрометации (IoC) и образцы можно найти в наш репозиторий GitHub.

Техники MITER ATT & CK

Эта таблица была построена с использованием версия 11 каркаса MITER ATT & CK.