У вирусных аналитиков есть небольшая профессиональная трагедия: работать с вредоносами обычно скучнее, чем может казаться по их вычурным названиям. За каждым новым ShadowSomething RAT/Loader/Stealer почти всегда скрывается один и тот же набор знакомых техник: загрузчик, закрепление в системе, канал связи с C2, немного обфускации «для галочки».

Но иногда попадаются образцы, которые действительно удивляют. В недавнем расследовании нам встретился именно такой. Речь пойдет о PhantomRShell — бэкдоре группировки PhantomCore (Head Mare), атакующей компании из России и Беларуси.

Главная «фишка» PhantomRShell — в том, как он маскирует свое присутствие в системе. Вредонос использует встроенный дизассемблер, чтобы перехватывать системные вызовы и скрывать свои файлы от пользователя и защитных инструментов. Проще говоря: файл лежит на диске, но для средств анализа его как будто не существует. 

На связи Александр, вирусный аналитик отдела реагирования Бастиона и автор телеграм-канала @section_remadev. Сегодня разберем, как устроен PhantomRShell: от цепочки заражения до механизма сокрытия, который делает этот бэкдор заметно интереснее большинства его «коллег по цеху».

Сэмпл схож с тем, что описывали наши коллеги из Positive Technologies. Отдавая должное их работе, разберем этот вредонос подробнее — с акцентом на внутреннюю механику перехватчика API, неочевидные способы инициализации и обход защиты.

Исходный образец — файл Задание_на_оценку_N_2046_от_05_августа_2025_года.zip — представляет собой, на первый взгляд, обычный ZIP-архив. Но если открыть его в HEX-редакторе, можно обнаружить совершенно другую сигнатуру — MZ/PE заголовок.

Перед нами стандартный архив-полиглот, включающий в себя 2 сторонних заголовка: DLL и PDF. При распаковке архива получаем еще один, третий, компонент — ярлык LNK. Давайте с него и начнем.

Задание_на_оценку_N_2046

Файл, маскирующийся под PDF-документ, на самом деле является ярлыком Windows (LNK). Именно с него начинается цепочка заражения. При открытии ярлык инициирует выполнение PowerShell-скрипта, который последовательно подготавливает систему к загрузке вредоносной библиотеки.

Первый этап — закрепление в системе через COM-Hijacking. Скрипт создает ключ в реестре по пути:

HKCU:\Software\Classes\CLSID\{c53e07ec-25f3-4093-aa39-fc67ea22e99d}\InprocServer32

При обращении к COM-объекту исходный ключ, находящийся в корне HKEY_CLASSES_ROOT, имеет приоритет ниже, чем тот же ключ, созданный в корне HKEY_CURRENT_USER. Значение по умолчанию в новом ключе содержит путь к будущему вредоносному модулю. В итоге вместо легитимной библиотеки %WinDir%\System32\Windows.StateRepositoryPS.dll системные процессы будут загружать библиотеку злоумышленника — %ProgramData%\winnt64_.dll.

Такой подход решает сразу несколько задач:

• Во-первых, вредоносный код начинает исполняться в контексте доверенных процессов, например, explorer.exe, что снижает вероятность детектирования.

• Во-вторых, обеспечивается закрепление: подмена сохраняется в реестре и переживает перезагрузку системы.

• Наконец, выполнение в доверенном процессе позволяет частично обходить защитные механизмы вроде UAC, AppLocker и WDAC.

После закрепления скрипт переходит к извлечению полезной нагрузки из исходного архива-полиглота. Он последовательно ищет исходный архив-полиглот в нескольких директориях: текущей папке, профиле пользователя (%USERPROFILE%) и временной директории (%TEMP%). Найдя подходящий файл, скрипт начинает читать его не как архив, а как бинарный поток.

Сначала пропускаются первые 16 байт. Это простая, но эффективная попытка обойти сигнатурный анализ, так как многие YARA-правила анализируют заголовок по первым байтам. Для PE-файлов это выглядит так:

uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550

После этого считывается блок размером 642 064 байта, который сохраняется в %ProgramData%\winnt64_.dll. Именно этот файл впоследствии будет подгружаться через COM-Hijacking.

Следующий блок данных размером 225 723 байта извлекается как PDF-документ и сохраняется по пути:

C:\sponge-bob\exe-zip-injector\Задание_на_оценку_N_2046_от_05_августа_2025_года.pdf

На этом этапе вредонос завершает техническую часть загрузки и переходит к маскировке своей активности. Извлеченный PDF-файл открывается стандартными средствами системы и представляет собой безобидный документ — приложение к договору. Это типичный прием отвлечения внимания: пользователь получает ожидаемый файл и не подозревает, что основная нагрузка уже внедрена в систему.

Важный нюанс, выявленный в ходе анализа: исходный PowerShell-скрипт, извлеченный из LNK-файла, содержит явно прописанный абсолютный путь к PDF-приманке. В исследуемом случае на узле жертвы данная директория отсутствовала, поэтому попытка открыть файл-приманку завершилась неудачей. Однако это не повлияло на ключевые этапы заражения. По всей видимости, атакующие просто пропатчили сетевую конфигурацию исходного вредоносного файла.

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

%ProgramData%\winnt64_.dll

Вредоносная библиотека — основной компонент этой атаки. В ходе анализа удалось обнаружить, что она содержит модуль перехватчика системных API. Это модуль Mhook.

Когда вызывается DllMain в контексте присоединения к какому-либо процессу (fdwReason = DLL_PROCESS_ATTACH), вызывается функция QueueUserWorkItem, позволяющая выполнить функцию перехватчика после освобождения потока.

Как работает перехватчик?

Сам хук хранится не как «один адрес», а в виде структуры trampoline:

00000000 struct MHOOKS_TRAMPOLINE // sizeof=0x88
00000000 {
00000000     PBYTE pSystemFunction;
00000008     DWORD cbOverwrittenCode;
0000000C     // padding byte
0000000D     // padding byte
0000000E     // padding byte
0000000F     // padding byte
00000010     PBYTE pHookFunction;
00000018     BYTE codeJumpToHookFunction[32];
00000038     BYTE codeTrampoline[32];
00000058     BYTE codeUntouched[32];
00000078     struct MHOOKS_TRAMPOLINE *pPrevTrampoline;
00000080     struct MHOOKS_TRAMPOLINE *pNextTrampoline;
00000088 };

Алгоритм установки можно понимать как цепочку из нескольких фаз. Сначала mhook пытается добраться до «настоящего» начала функции, пропуская типовые заглушки. Это hotpatch-пролог, collapsed stackframe и цепочки безусловных прыжков, включая import thunk. Это делает функция SkipJumps, чтобы библиотека не ставила хук на промежуточную обертку вместо реального кода.

Дальше идет самое важное: разбор машинного кода по инструкциям, а не побайтно. Для этого используется disasm-lib. Функция DisassembleAndSkip читает инструкции от начала целевой функции, суммирует их длины, пока не наберет минимум для патча, и останавливается, если встречается ret, условный переход или вызов. На x64 она дополнительно фиксирует инструкции с адресацией RIP-relative, потому что после переноса в структуру хука их смещения нужно будет пересчитывать. Это защита от «разрезания» инструкции пополам, из-за чего обычный memcpy пролога был бы опасен.

Mhook старается выделить память рядом с оригинальной функцией, потому что для обычного короткого перехода используется jmp rel32 (код операции E9), а он ограничен дальностью по адресу. Функция EmitJump выбирает самый короткий вариант: если цель достаточно близко, пишет 5-байтный E9 rel32, если далеко — пишет косвенный абсолютный прыжок, использующий RIP-relative, который на х64 занимает больше байт, но не зависит от близости адресов. Поэтому trampoline-блок стараются разместить как можно ближе к целевой функции.

Размещение памяти тоже неслучайное. Функция BlockAlloc проходит по свободным регионам памяти через VirtualQuery, ищет подходящий MEM_FREE-диапазон и выделяет в нем отдельную страницу памяти (или 4096 байт) с доступом RWX. Затем этот блок разбивается на набор структур MHOOKS_TRAMPOLINE, которые попадают в free list и используются для будущих хуков.

Чтобы избежать состояния гонки (race condition), Mhook временно останавливает остальные потоки процесса. С помощью SuspendOtherThreads mhook повышает приоритет текущего потока, берет снимок процессов/потоков через ZwQuerySystemInformation, проходит по всем потокам текущего процесса и по одному пытается их приостановить. Функция SuspendOneThread проверяет указатель инструкции потока через GetThreadContext. Если он указывает на область, которая будет перезаписана, поток временно возобновляют и пробуют приостановить повторно. Только после этого поток считается безопасно замороженным. Это сделано именно для того, чтобы не перезаписать код под выполняющимся потоком.

После этого библиотека может безопасно патчить вход функции. Сначала первые N целых инструкций оригинальной функции копируются в trampoline, к их концу дописывается прыжок обратно в original + overwritten_len, а сам вход оригинала затирается прыжком на hook-функцию. Если на x64 были RIP-relative addressing инструкции, функция FixupIPRelativeAddressing корректирует их перемещение с учетом разницы между адресом в trampoline и оригинальным адресом.

Если подытожить, то Mhook реализует не просто замену первых 5 байт, а полноценную inline-hooking схему: находит реальный EP, корректно разбирает инструкции, выделяет trampoline около функции, копирует и при необходимости правит перенесенный пролог, ставит jmp на хук, а затем временно останавливает потоковую среду во время записи.

Что перехватывается?

В нашем случае перехватывается NtQueryDirectoryFile — это NTAPI- функция, которая перечисляет содержимое каталога и возвращает информацию о файлах и каталогах. Она возвращает буфер со списком файлов, где каждый элемент — структура FILE_ID_BOTH_DIR_INFORMATION:

00000000 struct _FILE_ID_BOTH_DIR_INFORMATION // sizeof=0x70
00000000 {                                       
00000000     ULONG NextEntryOffset;
00000004     ULONG FileIndex;
00000008     LARGE_INTEGER CreationTime;
00000010     LARGE_INTEGER LastAccessTime;
00000018     LARGE_INTEGER LastWriteTime;
00000020     LARGE_INTEGER ChangeTime;
00000028     LARGE_INTEGER EndOfFile;
00000030     LARGE_INTEGER AllocationSize;
00000038     ULONG FileAttributes;
0000003C     ULONG FileNameLength;
00000040     ULONG EaSize;
00000044     CCHAR ShortNameLength;
00000045     // padding byte
00000046     WCHAR ShortName[12];
0000005E     // padding byte
0000005F     // padding byte
00000060     LARGE_INTEGER FileId;
00000068     WCHAR FileName[1];
0000006A     // padding byte
0000006B     // padding byte
0000006C     // padding byte
0000006D     // padding byte
0000006E     // padding byte
0000006F     // padding byte
00000070 };

На самом деле это классический односвязный список, где указатель на следующий элемент хранится в поле NextEntryOffset.

По аналогии со связным списком здесь так же реализован метод pop(), который удаляет элемент списка, если в поле FileName будет найдено вхождение строки «winnt64_.dll». Давайте наглядно посмотрим на пример работы такого механизма сокрытия. Библиотека инжектирована в процесс explorer.exe и должна находиться в каталоге %ProgramData%:

Однако в cmd.exe библиотека не инжектируется, поэтому при вводе команды dir в этом процессе файл будет отображаться:

Также хочется отметить, что в случае, если файл, который необходимо скрыть, находится в голове списка, элемент из структуры FILE_ID_BOTH_DIR_INFORMATION удален не будет. Вместо этого просто будут «обнулены» имя файла и его длина, что может быть достаточным основанием для детектирования вредоносной активности.

Скрытая инициализация и расшифровка конфигурации

Прежде чем вредонос начинает сетевое взаимодействие, происходит еще один важный этап, который легко упустить при поверхностном анализе. Речь идет о механизме скрытого хранения и «ленивой» расшифровки конфигурации.

Интересно, что функция расшифровки не вызывается напрямую из кода полезной нагрузки. Вместо этого она помещена в секцию .CRT$XCU, которая используется рантаймом Visual C++ для регистрации пользовательских инициализаторов. Во время старта процесса такие функции автоматически вызываются через _initterm, еще до передачи управления основной логике DLL. Вот как это выглядит:

Функция dllmain_crt_process_attach вызывает initterm(__xc_a, __xc_z):

Линкер объединяет смещения .CRT$XCA – .CRT$XCZ в один массив:

И вызывает initterm:

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

Еще один важный момент: где именно хранится результат. Вместо глобальных переменных или статических буферов вредонос использует TLS (Thread Local Storage). Доступ к данным осуществляется через ThreadLocalStoragePointer структуры TEB (Thread Environment Block), что позволяет хранить конфигурацию отдельно для каждого потока.

При первом обращении функция C2Decrypt проверяет флаг инициализации внутри кастомной TLS-структуры:

00000000 struct TLS_DATA // sizeof=0x4D
00000000 {
00000000     BYTE pad0[4];
00000004     char c2_ip[14];
00000012     BYTE c2_encrypted;
00000013     BYTE pad1;
00000014     BYTE c2_initialized;
00000015     char str2[24];
0000002D     BYTE str2_decrypted;
0000002E     BYTE pad2[2];
00000030     BYTE str2_initialized;
00000031     char str3[25];
0000004A     BYTE str3_decrypted;
0000004B     BYTE pad3;
0000004C     BYTE str3_initialized;
0000004D };

Если данные еще не подготовлены, записывает туда зашифрованные значения. После этого выполняется их побайтная дешифровка с помощью XOR:

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

Такой подход дает сразу несколько преимуществ:

• отсутствие статических IOC в бинарном файле;

• усложнение статического анализа;

• привязка конфигурации к контексту потока;

• неочевидный момент инициализации через CRT.

В результате даже при полном разборе кода можно не сразу понять, откуда берутся строки, используемые в сетевом взаимодействии.

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

Сетевой протокол

Прежде чем переходить к полезной нагрузке, стоит осветить некоторые подготовительные действия, которые происходят в функции 0x1800110E0. Несмотря на обилие «мусорной» обфускации, занимающей почти 300 строк псевдокода, подготовка включает в себя всего 4 действия:

1. Генерация уникального ID

Происходит с помощью инициализации COM GUID. Этот GUID далее будет использоваться для идентификации зараженного узла.

2. Сбор информации о системе

Или получение имени компьютера и домена с помощью GetComputerNameW и GetComputerNameExW. Информация также будет использоваться при взаимодействии с С2.

3. Подготовка рабочей директории

С помощью CreateDirectoryW создается рабочая директория %ProgramData%\IntelHVD, в которой будут сохраняться файлы, установленные управляющим сервером.

4. Запуск отдельного потока для взаимодействия с С2

Создание потока осуществляется с помощью beginthreadex, в котором и будет работать код полезной нагрузки.

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

В образце группировки PhantomCore я заметил два ключевых паттерна:

• «Мусорный» код, занимающий примерно 90% листинга, выглядит так:
  ((dword_180097808 * (dword_180097808 - 1)) & 1) != 0 && dword_18009780C > 9 )

• Обфускация с помощью RUNTIME:
  ((off_180095E60 + 0x3481BC8BD8B81103LL))(v62, v63, v59, v54);
((off_180095E60 + 0x3481BC8BD8B81103LL))(v62, v63, v59, v54);

Новые версии IDA Pro зачастую неплохо справляются с RUNTIME обфускацией, но комбинация двух этих методов может вызывать у инструмента трудности. Правим вручную, устанавливая нужное смещение как QWORD и изменяя его тип на const __int64:

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

После приведения функции в читаемый вид мы видим вполне привычную для бэкдоров схему управления С2. Обмен с сервером строится по классической pull-модели. Сначала образец отправляет GET-запрос на адрес http://31.56.206[.]116/poll, передавая в параметрах id (GUID, который был сгенерирован ранее), hostname и domain. Значения упакованы в строку вида id=<GUID>&hostname=<host>&domain=<domain>, то есть трафик маскируется под обычную веб-форму.

В ответ сервер возвращает строку с командами, разделенными пайпом:

Команды выполняются с помощью создания процесса cmd.exe. Параметр запуска «cmd.exe /c» так же хранится в зашифрованном виде в TLS:

Результат выполнения команды отправляется отдельным POST-запросом на эндпоинт /result. Данные передаются не в заголовках, а в теле запроса, в формате application/x-www-form-urlencoded. В запросе используются поля id, hostname, domain, result (результат выполнения команды) и commandId (идентификатор команды). За счет этого трафик выглядит как обычное взаимодействие клиентского приложения с веб-сервисом, хотя по сути перед нами полноценный канал управления.

Заключение

PhantomRShell — продуманный инструмент, применяющий нестандартные методы маскировки. Злоумышленники показали, как техники, обычно применяемые для исследования, могут быть обращены против самой системы.

При этом его сетевая составляющая, напротив, мимикрирует под обычный веб-трафик, что затрудняет выявление по сетевым потокам. Такой дисбаланс типичен для современных таргетированных атак.

Ниже приведены индикаторы компрометации, которые помогут распознать присутствие этого бэкдора в корпоративной сети: