В конце мая стало известно о том, что хакеры пытались организовать вредоносную рассылку якобы от Минцифры. Архив из этой рассылки получили для анализа специалисты Solar JSOC CERT. В нем мы обнаружили jli.dll. Эту DLL часто используют злоумышленники для размещения вредоносного кода, так как с помощью техники DLL Side Loading её подгружает довольно большое число легитимных файлов. Но в данном кейсе DLL использовалась по-другому – в рамках одного стандартного приложения Java. А как именно – расскажем в этом посте.
В новостях об атаке говорилось, что ВПО предположительно распространялось как почтовый червь и содержалось во вложениях писем, поступающих с адреса minspecsvyaz@mail.ru. Рассылаемое письмо выглядело следующим образом:
Известные приемы социальной инженерии видны невооруженным взглядом:
использование насущной темы («Суверенный интернет»);
ссылки на официальные документы;
оформление письма;
и, конечно, фишинговая ссылка.
На момент анализа фишинговый ресурс minspecsvyz.ru/validator уже был недоступен, но, скорее всего, он содержал инструкцию по проверке подключения, откуда можно было загрузить полученный нами архив.
Структура архива представляет собой урезанный образ Java-приложения (app image):
Приведем описание каждого файла.
Имя файла |
Описание |
app/validator.dll |
Библиотека на .NET – основной вредоносный файл. |
app/Запустить валидатор.cfg |
Конфигурационный файл, сгенерированный стандартной Java-утилитой jpackage. |
runtime/bin/jli.dll |
Та самая jli.dll, в которой одна из экспортных функций подменена на вредоносную. |
runtime/bin/vcruntime140.dll |
Легитимные библиотеки, которые не используются и, скорее всего, были оставлены в каталоге для создания иллюзии, что в данном каталоге все файлы легитимны. |
runtime/bin/vcruntime140_1.dll | |
Запустить валидатор.exe |
Стандартный файл jpackageapplauncherw.exe |
Контрольные суммы файлов представлены в последнем разделе.
Цепочка запуска основной библиотеки
Запустить валидатор.exe – 64-битный исполняемый файл с эмблемой войск связи ВС РФ.
Дата компиляции – 06.05.2070 09:18:22 UTC.
PDB-путь – jpackageapplauncherw.pdb.
Файл содержит две VERSIONINFO структуры. Одна – для всех локализаций, ее данные отображаются в проводнике Windows – содержит пользовательские метаданные. Другая – для языка English - United States –содержит данные о среде выполнения Java.
PDB-путь и данные из структуры VERSIONINFO указывают, что файл был создан с помощью стандартной Java-утилиты jpackage, которая позволяет упаковывать Java-приложения в различные форматы исполняемых файлов, а также формировать образы приложений.
Исходный код данной утилиты публично доступен.
После изучения исходного кода выяснилось, что файл Запустить валидатор.exe представляет собой файл jpackageapplauncherw.exe с измененными метаданными и иконкой. Сам исходный файл, который jpackage использует в своей работе, доступен по следующему пути (используем jdk-17-.0.2, чтобы launcher’ы совпадали с имеющимся у нас): jdk-17.0.2_windows-x64_bin.zip\jmods\jdk.jpackage.jmod\classes\jdk\jpackage\internal\resources\jpackageapplauncherw.exe
Архив доступен для загрузки по ссылке.
Перед анализом содержимого образа Java-приложения, рассмотрим, как он создается и из чего состоит, на простом примере. Упакуем следующее Java-приложение в app-image:
Получаем class-файл с помощью: javac.exe Main.java
Создадим файл MANIFEST.mf со следующим содержимым (перевод строки обязателен):
Создадим jar-файл: jar.exe -cvfm test.jar MANIFEST.mf ru\minsvyaz\Main.class
Создадим образ Java-приложения с помощью jpackage:
jpackage.exe --type app-image -i <input_dir> --main-jar test.jar --name validator --win-console, где:
<input_dir> – путь до каталога с jar-файлом;
<path-to-main-jar-file> – путь до основного jar-файла, относительно <input_dir>;
--win-console – необходимо для отображения сообщений в консоле;
--name – название app-image (каталога с результатами работы jpackage)
В результате выполнения данной команды под капотом jpackage сначала использует jlink, чтобы создать среду выполнения Java (каталог runtime). Затем создает конфигурационный файл (cfg-файл) для jpackageapplauncher и копирует файлы из <input_dir> в результирующий каталог validator.
В результате получается следующая структура каталогов:
Содержимое app\validator.cfg:
Запуск validator.exe (jpackageapplauncherw):
jpackageapplauncherw при своём запуске читает конфигурационный файл из каталога app, подгружает jli.dll из каталога runtime\bin с помощью WinAPI-вызова LoadLibraryExW и выполняет запуск виртуальной машины Java с параметрами из cfg-файла. Для её запуска используется вызов экспортной функции JLI_Launch библиотеки runtime\bin\jli.dll.
Конфигурационный файл Запустить валидатор.cfg содержал следующие данные:
Странным являются два факта:
наличие двух classpath, так как jpackage принимает только один jar-файл в опции --main-jar;
отсутствие jar-файлов в каталоге app.
Помимо этого, в каталоге runtime\bin присутствовали только файлы jli.dll, vcruntime140.dll и vcruntime140_1.dll и отсутствовали остальные каталоги conf, legal, lib. Всё это было удалено за ненадобностью.
В нашем случае даже содержимое конфигурационного файла не имеет значения (он может быть пустым, для jpackagelauncherw главное, чтобы этот файл существовал), так как библиотека jli.dll вовсе не собирается запускать Java-машину. У неё отсутствует цифровая подпись, и она весит в два раза меньше оригинальной. Это все из-за того, что код функции JLI_Launch был изменён:
Таким образом, экспортная функция JLI_Launch просто запускает файл app\Validator.dll. Стоит отметить, что остальные экспортные функции и метаданные файла соответствовали оригинальной DLL.
Итоговая цепочка запуска: Запустить валидатор.exe (jpackageapplauncherw) > jli.dll!JLI_Launch > app\validator.dll.
Функционал validator.dll
validator.dll – это 32-разрядная необфусцированная DLL на .NET.
Даты компиляции: в будущем (> 2040 г.).
PDB-путь: C:\Users\1\source\repos\hackamakafon\SocketClient2\TestFirstIteration\obj\Release\Validator.pdb
Основной функционал – кража документов.
При запуске отображает следующие окна:
Перед отправкой сообщения об успешной проверке маршрутизации выполняются следующие действия:
генерируется случайный ID клиента (через Guid.NewGuid());
загружается на FTP-сервер список установленных программ из ключа реестра HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall под именем clientID_startTime.info;
загружаются на FTP-сервер файлы заданных расширений рекурсивно
из заданных каталогов системного диска;загружаются на FTP-сервер файлы заданных форматов рекурсивно
с других логических дисков (кроме диска C).
Время представляется как количество миллисекунд с 12:00:00 01.01.01.
Запись украденных файлов выполняется в один файл, который каждые 90 МБ меняется.
Формат имён файлов-частей clientID_startTime_chunkStartTime.part, где:
startTime – время начала записи файлов для текущего clientID, то есть это время начала передачи данных;
chunkStartTime – время начала записи для текущей части файла.
Переход к записи в следующий файл на FTP выполняется каждые 90 МБ.
Формат данных внутри файла
Тип данных |
Название параметра |
Параметр файла |
dword |
filename_length |
длина имени |
char |
filename[filename_length] |
имя |
qword |
file_size |
длина содержимого |
char |
file_contents[file_size] |
содержимое |
Заданные расширения собираемых файлов:
Заданные каталоги системного диска:
Также был обнаружен неиспользуемый класс WebDavSender со следующими данными:
Выводы
И пусть jli.dll известна давно, злоумышленники находят новые способы запуска вредоносного кода. Тем не менее, вся эта цепочка запусков должна хорошо детектироваться средствами защиты информации.
Хостовые индикаторы компрометации:
Имя файла |
SHA256 |
Validator-dc352.zip |
32ca5ffefe5d6d6c7918f5839ce47dc6035a33a222701bd0bee26208d6302d80 |
app/validator.dll |
c9364af38d33a7a417baef728fc0fa413082b0cf130fc8ac6ff6a5c790ebf264 |
app/Запустить валидатор.cfg |
7b86ecc8eb55935281430e0be1d3873295f5faa1e2c05126627179cfaf433131 |
runtime/bin/jli.dll |
8326e74371f52ce4bc71ad3983ed971b2618228ddce13ca977e67b6e35590152 |
Запустить валидатор.exe |
640dd96069ce6c54abf1df3f55682808e5c5bf95379f12d99fb2dd859e4070e0 |
Сетевые индикаторы компрометации:
st23419.ispot.cc
3.64.76.72
Автор: Антон Каргин, инженер технического расследования "РТК-Солар".