#ParsedReport #ChatGPT #Translated
Autotext: (TI Report Analyser + ChatGPT + Auto Translate)

------
Кампания MovieReaper отравила торрент-файлы на itorrents.org, распространяя загрузчики с тематикой фильмов в нескольких странах. Многоэтапное ВПО использовало методы противодействия анализу, ручное разрешение API, выполнение шеллкода и HTTPS C2, при этом данные блокчейна Solana скрывали адрес вторичного сервера. Его имплант выполнял COFF-модули в оперативной памяти и обеспечивал закрепление с использованием техник обхода UAC.
-----

В середине августа 2026 года кампания под названием MovieReaper распространяла модульный многоэтапный фреймворк вредоносного ПО через скомпрометированную торрент-инфраструктуру. Злоумышленники внесли изменения в торрент-файлы, размещенные на itorrents.org — публичном репозитории, используемом несколькими торрент-трекерами. Магнитные ссылки, которые обычно возвращали легитимные торрент-архивы, вместо этого доставляли вредоносные торренты, содержащие исполняемые загрузчики, замаскированные под фильмы и другой популярный контент. Кампания затронула физических лиц и организации в странах Европы, Азии и Африки, включая Россию, Турцию, Японию, Кению, Уганду, Колумбию, Испанию, Германию и Нидерланды.

Первоначальный загрузчик использовал длинные имена файлов и значки, имитирующие легитимные приложения, чтобы скрыть свою исполняемую природу. Он избегал стандартных вызовов LoadLibrary и GetProcAddress, определяя загруженные модули через блок среды процесса Windows (Process Environment Block) и вручную разрешая экспортированные функции. После выполнения проверок на антианализ он устанавливал соединение с deadhub.org по протоколу HTTPS, при этом 193.23.118.155 служил резервным каналом для передачи данных в открытом виде по HTTP, и загружал шеллкод несколькими частями, используя рандомизированные пути URL. Загрузчик отображал шеллкод в память с правами RWX и выполнял его с помощью прямых системных вызовов, векторной обработки исключений и недокументированной функции EtwpCreateEtwThread.

На втором этапе вредоносный код обращался к блокчейну Solana через RPC-эндпоинт api.mainnet.solana.com, получая данные, связанные с аккаунтом 6pnDGAiHgyPdmckM5Qt1YbanGzrX43WLEU159nRaNLDm. В ответе содержался адрес второго сервера управления, закодированный в base64 и зашифрованный с помощью XOR. Последующие коммуникации осуществлялись по протоколу HTTPS с фиксацией сертификата (certificate pinning) и использованием nanopb Protocol Buffers. Вредоносный модуль мог получать файлы в формате COFF, загружать их непосредственно в память и выполнять их функции module_init, что позволяло расширять функциональность.

Модуль третьей стадии выполнял обход UAC и закрепление с использованием общедоступных техник. Он копировался или маскировался под C:\ProgramData\Microsoft\Windows\Telemetry\msedge.exe и перезапускал себя. Перезапущенный процесс использовал аргумент командной строки для обхода большинства проверок песочниц, при этом его бикон указывал на то, что он выполняется из каталога Telemetry. Хранение на основе Solana повышало устойчивость, позволяя изменять адреса C2 без полного опора на фиксированную серверную инфраструктуру.