Грекоязычные деловые письма служили приманкой для загрузки XLoader
В кампании деловые письма на греческом языке с приманками в виде заказов и платежей доставляли архивы RAR. Внутри находился обфусцированный файл JScript, а не легитимный документ. Цепочка включала загрузчик на Lua и вредоносное ПО XLoader, которое внедряло код в выбранный процесс x86.
Доставка и работа загрузчика на Lua
Файл JScript содержал исполняемый файл, совместимый с x86 LuaJIT, и файл с исходным кодом Lua без расширения. Оба компонента декодировались из данных Base64 и записывались в каталог Documents пользователя. Затем запускался LuaJIT с файлом Lua в качестве входного, при этом окно процесса скрывалось.
Загрузчик на Lua использовал LuaJIT FFI для вызова API Windows, скрытия консоли и попыток вмешательства в механизмы защиты на уровне процесса. Он искал в памяти CLR функции AmsiScanBuffer и AmsiInitialize, а также пытался подменить несколько экспортов ntdll, связанных с управлением ETW, потоками, процессами и секциями. Начальные байты этих экспортов заменялись инструкцией возврата и NOP.
В загрузчике также была условная возможность закрепления. Она позволяла создать запланированную задачу с именем EHFTUOMQDRXVTJSF, которая запускала VBS-загрузчик каждые десять минут. В ходе анализа выполнения это поведение не подтвердилось.
Загрузка и запуск XLoader
В исходном коде Lua был встроен закодированный PE-файл. После подстановки, инверсии, декодирования с использованием пользовательского варианта Base64, ротации символов и удаления управляющего байта из него получался упакованный 32-разрядный PE-образ. Загрузчик на Lua вручную отображал образ в текущий процесс LuaJIT и создавал в нём поток.
У упакованного PE не было таблицы импорта. Функцию NtAllocateVirtualMemory загрузчик находил, обходя блок среды процесса и разбирая экспорты ntdll. Он выделял память с правами на выполнение и запись, копировал туда полезную нагрузку, расшифровывал ядро XLoader и запускал его в том же потоке LuaJIT.
XLoader готовил клон своей ступени и переносил выполнение в выбранный процесс x86. Он отображал общий раздел в обоих процессах, копировал клонированный код через локальное отображение, перенаправлял контекст выполнения управляемого потока на удалённое отображение и возобновлял работу потока. Это составляло этап внедрения кода в процессы в рамках цепочки.
Конфигурация и возможности XLoader
Восстановленная сборка XLoader использовала защищённые функции, сетевые маркеры PKT2:, параметры HTTP POST, включая dat=, &un= и &br=9, а также WinINet и «сырые» сокеты для связи. В конфигурации содержалось несколько кандидатов в именах узлов и путях, в том числе www.990match.com.
Функциональные возможности сборки включали обработку команд, загрузку данных по HTTP, перечисление содержимого хранилища Windows Vault и сбор данных, связанных с файлами cookie браузера.
Отчет получен из сервиса CTT Report Hub. Права на отчет принадлежат его владельцу.
Ознакомиться подробнее с отчетом можно по ссылке.
