Как группировка APT41 реанимировала буткит BlackLotus и нацелилась на дипломатические организации в Центральной Азии

Введение

В октябре 2022 года эксперты Глобального центра исследования и анализа угроз (GReAT) «Лаборатории Касперского» исследовали необычное объявление на хакерском форуме. Некий киберпреступник продавал UEFI-буткит BlackLotus, способный обходить протокол Secure Boot, за 5000 долл. США. Такой мощный инструмент должен был стоить куда больше, поэтому сообщество специалистов по кибербезопасности поначалу восприняло этот пост скептически. Проверить заявления хакера не представлялось возможным, ведь образцов BlackLotus в реальных атаках обнаружено не было.

Объявление о продаже BlackLotus

Однако спустя почти шесть месяцев, в марте 2023 года, компания ESET подтвердила подлинность объявления о BlackLotus. Исследователям компании удалось найти образцы буткита и убедиться, что он действительно позволяет обходить Secure Boot, эксплуатируя уязвимость Baton Drop (CVE-2022-21894). Поскольку в 2023 году эта уязвимость все еще была актуальна, компания Microsoft выпустила несколько обновлений безопасности для ее устранения.

После выхода патчей буткит BlackLotus ушел в тень: публично известных атак с его использованием не наблюдалось. Тем не менее в начале 2026 года мы обнаружили образец вредоносного ПО, схожий с BlackLotus, который использовался в APT-кампании в Центральной Азии. В этом отчете мы представляем детали нашего исследования, включая новые образцы вредоносной нагрузки и возможную атрибуцию этой кампании.

Возвращение нашумевшего буткита

В начале 2026 года мы обнаружили сложную APT-атаку на дипломатические ведомства стран Центральной Азии: Таджикистана, Узбекистана и Туркменистана. Атакующие применяли UEFI-буткит, который мы назвали BlackX. Проанализировав его, мы обнаружили сходство с BlackLotus.

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

• inst.exe — исполняемый файл установщика;
• PVMDIJGKAX2 — зашифрованный по алгоритму RC4 файл без расширения. В нем содержатся файлы и строки, необходимые для установки.

Установщик запускался с помощью командной строки C:\ProgramData\Intel\inst.exe PVMDIJGKAX2 Q46F6MDLI3RX2KV1. Последний аргумент — это ключ RC4, используемый для расшифровки.

Любопытно, что файл inst.exe не содержит ни вредоносных строк, ни встроенных блоков с данными. Все файлы, необходимые для установки вредоносной нагрузки, находятся внутри PVMDIJGKAX2. Такой подход призван усложнить специалистам задачу по извлечению компонентов буткита.

Пакет с установщиком размещает в системном разделе и разделе UEFI набор файлов, предназначенных для эксплуатации уязвимости Baton Drop. Мы отметили, что реализация эксплойта очень похожа на ту, что применялась в зловреде BlackLotus. Как и в случае с BlackLotus, цель эксплойта — установить пользовательские ключи владельца компьютера (Machine Owner Keys, MOK). Это позволяет загружать произвольные EFI-файлы в целевые системы и манипулировать работой Secure Boot.

Хотя реализация цепочки эксплуатации очень похожа на таковую в BlackLotus, мы обнаружили различия между эксплойтами, найденными в BlackLotus и BlackX. При этом исходный код буткита BlackLotus никогда не публиковался в интернете. Это может означать, что злоумышленники, стоящие за BlackX, либо провели реверс-инжиниринг буткита, либо заплатили за его исходный код. В любом случае это интересно, поскольку APT-группировки редко заимствуют идеи и код у киберпреступников.

Вредоносная нагрузка, запускаемая буткитом

UEFI-модуль, доставляемый при эксплуатации уязвимости Baton Drop, преследует типичную для буткитов цель — внедрить вредоносный драйвер в ядро ОС Windows. Драйвер отличается от того, который устанавливался BlackLotus, и подписан сертификатом организации 温江区明宇网络技术服务工作室 (Wenjiang District Mingyu Network Technology Service Studio). На момент написания статьи этот сертификат (серийный номер: 0bcdf5e0da32d68900b8b7638459d072) отозван его издателем.

Задача драйвера — вмешиваться в работу защитных решений, установленных на компьютере. Например, драйвер отключает обратные вызовы процессов, потоков и реестра, связанные с защитными решениями. Кроме того, он вмешивается в работу поставщиков ETW, чтобы защитные решения не могли получать от них выходные данные. Любопытно, что часть этих вредоносных процессов запускается, только если на зараженном компьютере установлены решения «Лаборатории Касперского» или Avast. Однако динамический анализ драйвера показал, что эти процедуры бесполезны и никак не мешают работе наших продуктов.

Вредоносный драйвер также защищает файлы буткита от вмешательства. Он перехватывает запросы ядра на открытие этих файлов и вместо дескриптора вредоносного файла возвращает дескриптор calc.exe.

Модули второго этапа

Помимо вмешательства в работу защитных решений, драйвер отвечает за развертывание вредоносных нагрузок, работающих в пользовательском режиме. Мы обнаружили две такие нагрузки для кибершпионажа в реальных атаках. Одна из них — троянец удаленного доступа (RAT), способный загружать написанные на .NET модули следующего этапа. Для связи с командным сервером троянец использует облачные хранилища: нам встречались версии, работающие через Google Drive, OneDrive и Яндекс Диск. Подключившись к облачному хранилищу, RAT перебирает доступные файлы и интерпретирует их в зависимости от расширения. Ниже приведен список поддерживаемых расширений.

Кроме того, мы обнаружили еще одну вредоносную нагрузку, доставляемую через буткит. Мы назвали ее OxiDLLRunner. Это динамическая библиотека (DLL), обфусцированная с помощью OLLVM. Она загружается легитимным файлом googleupdate.exe (исходное имя файла: jcef_helper.exe, MD5: AF8A983B9ADA07EAE1259BF2953ABD40), который тоже доставляется буткитом. Библиотека расшифровывает содержимое файла v8_context_snapshot.bin из той же папки, после чего переходит к началу расшифрованных данных. Они состоят из шелл-кода и следующего за ним PE-файла — модуля, написанного на Rust и предназначенного для связи с командным сервером по адресу www[.]archivetj[.]com. В ходе обмена данными эта нагрузка должна получать DLL-файлы, экспортирующие функцию create_plugin, которые затем запускаются в отдельных потоках.

Атрибуция

На основании приведенных ниже фактов мы со средней степенью уверенности отнесли эту атаку к деятельности группировки APT41.

• В июне 2026 года компания ESET описала в своем блоге атаки группировки FishMonger, которую специалисты связывают с APT41. В публикации описан имплант уровня ядра, путь к PDB-файлу которого начинается с C:\Users\xdd\Desktop. Авторы допускают, что в кампании мог применяться неизвестный UEFI-буткит, который эксплуатировал уязвимость CVE‑2023‑24932. Мы неоднократно встречали идентификатор xdd во вредоносных нагрузках буткита BlackX, поэтому полагаем, что BlackX и есть тот самый UEFI-буткит, о котором пишут исследователи из ESET.
• Вредоносные нагрузки, развертываемые буткитом BlackX, загружаются с помощью легитимного исполняемого файла (техника DLL sideloading) и зашифрованного файла. Такая схема часто применяется китаеязычными злоумышленниками.
• Файл OxiDLLRunner обфусцирован с помощью OLLVM — обфускатора, который также часто используют китаеязычные злоумышленники.

Как злоумышленникам удалось заразить атакованные организации

При первичном анализе BlackX мы полагали, что развернуть буткит удалось из-за халатности самих жертв. Уязвимость Baton Drop, которая эксплуатировалась при развертывании буткита, была обнаружена и исправлена еще в 2023 году, поэтому поначалу мы предположили, что на зараженных компьютерах еще не были установлены соответствующие исправления. Однако наше расследование показало, что это не так: на атакованных компьютерах были установлены все необходимые обновления.

Оказалось, что проблема заключалась в самом обновлении. Как выяснилось, патч для уязвимости Baton Drop должен отзывать сертификат Windows Production PCA 2011, которым подписаны уязвимые компоненты UEFI. Однако отзыв не происходит автоматически при установке обновления — пользователю необходимо запустить процесс вручную. Для этого нужно выполнить следующие действия:

• установить флаг в разделе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot;
• создать в планировщике задачу Secure-Boot-Update.

Патч по замыслу разработчиков должен применяться вручную, так как при автоматической установке могут, например, выйти из строя системы с двумя ОС, для запуска которых требуется сертификат Windows Production PCA 2011. При этом такая практика развертывания патча создает проблему: системные администраторы крайне редко выполняют дополнительные действия после установки обновления. Как правило, после установки патчей ручное вмешательство требуется, только если произошел сбой установки. Инструкции по активации упомянутого патча спрятаны на сайте Microsoft так глубоко, что рядовой ИТ-администратор вряд ли их заметит.

Любопытно, что в графике установки патчей для Baton Drop указан «этап принудительного применения» (Enforcement Phase), который предполагает автоматический отзыв сертификата Windows Production PCA 2011 без участия пользователя. На момент публикации этой статьи данный этап не реализован. Cрок действия сертификата истек 19 октября 2026 года, однако это не препятствует загрузке уязвимых исполняемых файлов, если сертификат не внесен в список блокировки.

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

Заключение

Управление исправлениями важно для любой организации, поскольку обновления, выпускаемые поставщиками, помогают защищать программное обеспечение и аппаратную часть от эксплуатации известных уязвимостей. Однако иногда установленные патчи не защищают от проблем, которые они призваны устранить. Описанная нами история с BlackLotus — не единственная в своем роде. Так, в 2025 году компания Microsoft выпустила исправление уязвимости ToolShell, которое также требовалось применить вручную.

Тем не менее современные защитные решения рассчитаны на случаи, когда установленные патчи по тем или иным причинам не решают проблем безопасности. Например, технология автоматической защиты от программ использования уязвимостей (Automatic Exploit Prevention, AEP) в продуктах «Лаборатории Касперского» предотвращает запуск эксплойтов, если соответствующее исправление не применено или используется уязвимость нулевого дня, для которой исправление еще не выпущено. Исходя из этого, крайне важно установить защитные решения на все компьютеры в организации и постоянно следить за оповещениями от них.