Jli.dll по-новому: как хакеры использовали известную DLL в фишинге якобы от имени Минцифры

В конце мая стало известно о том, что хакеры пытались организовать вредоносную рассылку якобы от Минцифры. Архив из этой рассылки получили для анализа специалисты Solar JSOC CERT. В нем мы обнаружили jli.dll. Эту DLL часто используют злоумышленники для размещения вредоносного кода, так как с помощью техники DLL Side Loading её подгружает довольно большое число легитимных файлов. Но в данном кейсе DLL использовалась по-другому – в рамках одного стандартного приложения Java. А как именно – расскажем в этом посте.

В новостях об атаке говорилось, что ВПО предположительно распространялось как почтовый червь и содержалось во вложениях писем, поступающих с адреса minspecsvyaz@mail.ru. Рассылаемое письмо выглядело следующим образом:

Известные приемы социальной инженерии видны невооруженным взглядом:

1. использование насущной темы («Суверенный интернет»);

2. ссылки на официальные документы;

3. оформление письма;

4. и, конечно, фишинговая ссылка.

На момент анализа фишинговый ресурс minspecsvyz.ru/validator уже был недоступен, но, скорее всего, он содержал инструкцию по проверке подключения, откуда можно было загрузить полученный нами архив.

Структура архива представляет собой урезанный образ Java-приложения (app image):

Приведем описание каждого файла.

Контрольные суммы файлов представлены в последнем разделе.

Цепочка запуска основной библиотеки

Запустить валидатор.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.zipjmodsjdk.jpackage.jmodclassesjdkjpackageinternalresourcesjpackageapplauncherw.exe

 Архив доступен для загрузки по ссылке.

Перед анализом содержимого образа Java-приложения, рассмотрим, как он создается и из чего состоит, на простом примере. Упакуем следующее Java-приложение в app-image:

Получаем class-файл с помощью: javac.exe Main.java

Создадим файл MANIFEST.mf со следующим содержимым (перевод строки обязателен):

Создадим jar-файл: jar.exe -cvfm test.jar MANIFEST.mf ruminsvyazMain.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.

В результате получается следующая структура каталогов:

Содержимое appvalidator.cfg:

Запуск validator.exe (jpackageapplauncherw):

jpackageapplauncherw при своём запуске читает конфигурационный файл из каталога app, подгружает jli.dll из каталога runtimebin с помощью WinAPI-вызова LoadLibraryExW и выполняет запуск виртуальной машины Java с параметрами из cfg-файла. Для её запуска используется вызов экспортной функции JLI_Launch библиотеки runtimebinjli.dll.

Конфигурационный файл Запустить валидатор.cfg содержал следующие данные:

Странным являются два факта:

• наличие двух classpath, так как jpackage принимает только один jar-файл в опции --main-jar;

• отсутствие jar-файлов в каталоге app.

Помимо этого, в каталоге runtimebin присутствовали только файлы jli.dll, vcruntime140.dll и vcruntime140_1.dll и отсутствовали остальные каталоги conf, legal, lib. Всё это было удалено за ненадобностью.

В нашем случае даже содержимое конфигурационного файла не имеет значения (он может быть пустым, для jpackagelauncherw главное, чтобы этот файл существовал), так как библиотека jli.dll вовсе не собирается запускать Java-машину. У неё отсутствует цифровая подпись, и она весит в два раза меньше оригинальной. Это все из-за того, что код функции JLI_Launch был изменён:

Таким образом, экспортная функция JLI_Launch просто запускает файл appValidator.dll. Стоит отметить, что остальные экспортные функции и метаданные файла соответствовали оригинальной DLL.

Итоговая цепочка запуска: Запустить валидатор.exe (jpackageapplauncherw) > jli.dll!JLI_Launch > appvalidator.dll.

Функционал validator.dll

validator.dll – это 32-разрядная необфусцированная DLL на .NET.

Даты компиляции: в будущем (> 2040 г.).

PDB-путь: C:Users1sourcereposhackamakafonSocketClient2TestFirstIterationobjReleaseValidator.pdb

 Основной функционал – кража документов.

 При запуске отображает следующие окна:

Перед отправкой сообщения об успешной проверке маршрутизации выполняются следующие действия:

• генерируется случайный ID клиента (через Guid.NewGuid());

• загружается на FTP-сервер список установленных программ из ключа реестра HKLM:SOFTWAREMicrosoftWindowsCurrentVersionUninstall под именем clientID_startTime.info;

• загружаются на FTP-сервер файлы заданных расширений рекурсивно
  из заданных каталогов системного диска;

• загружаются на FTP-сервер файлы заданных форматов рекурсивно
  с других логических дисков (кроме диска C).

Время представляется как количество миллисекунд с 12:00:00 01.01.01.

Запись украденных файлов выполняется в один файл, который каждые 90 МБ меняется.

Формат имён файлов-частей clientID_startTime_chunkStartTime.part, где:

startTime – время начала записи файлов для текущего clientID, то есть это время начала передачи данных;

chunkStartTime – время начала записи для текущей части файла.

Переход к записи в следующий файл на FTP выполняется каждые 90 МБ.

Формат данных внутри файла

Заданные расширения собираемых файлов:

Заданные каталоги системного диска:

Также был обнаружен неиспользуемый класс WebDavSender со следующими данными:

Выводы

И пусть jli.dll известна давно, злоумышленники находят новые способы запуска вредоносного кода. Тем не менее, вся эта цепочка запусков должна хорошо детектироваться средствами защиты информации.

Хостовые индикаторы компрометации:

Сетевые индикаторы компрометации:

 st23419.ispot.cc

3.64.76.72

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