Хакери използват нов буткит BlackX за заобикаляне на Windows Secure Boot на напълно обновени системи

Нов UEFI буткит, наречен BlackX, е бил използван в атаки за кибершпионаж срещу дипломатически организации в Таджикистан, Узбекистан и Туркменистан.

Зловредният софтуер атакува Secure Boot – функция, предназначена да спира стартирането на ненадежден софтуер преди зареждането на Windows.

Изследователите посочват, че заразените компютри са получили обновления за Windows, но ключова защита за Secure Boot не е била приложена напълно.

Анализаторите от Securelist докладваха констатациите на 22 октомври 2026 г. Те споделят, че BlackX използва уязвимостта Baton Drop, проследявана като CVE-2022-21894, и споделя елементи от архитектурата си с буткита BlackLotus.

Констатациите показват защо инсталираното обновяване невинаги означава, че защитата, която трябва да осигури, е напълно активирана. Докладът на Securelist за BlackX описва подробно зловредния софтуер и кампанията.

BlackX се инсталира, след като атакуващите вече са получили достъп до мрежата на жертвата и права на ниво администратор. Неговият инсталатор, inst.exe, работи с криптиран файл с име PVMDIJGKAX2, съдържащ компонентите, необходими за инсталирането на зловредния софтуер.

Securelist посочва, че този дизайн може да затрудни специалистите по реагиране на инциденти да извлекат всички части на буткита само от инсталатора. Буткитът използва Baton Drop, за да зареди контролирани от атакуващия EFI файлове и да наруши работата на Secure Boot.

EFI файловете се изпълняват по време на процеса на първоначално зареждане на компютъра, преди Windows да се зареди. Чрез заемане на позиция в тази ранна последователност буткитът може да даде възможност на зловредния код да се изпълни, преди много от инструментите за сигурност на операционната система да са се активирали.

Хакери използват нов буткит BlackX

Читателите могат да научат повече за свързаните рискове при първоначално зареждане в този доклад на Cybersecurity News относно управлението на настройките на UEFI Secure Boot.

Securelist посочва, че драйверът на ниво ядро (kernel driver) в кампанията се опитва да отслаби инструментите за сигурност чрез прекъсване на извикванията (callbacks) на процеси, нишки и системния регистър, както и чрез намеса в Event Tracing for Windows (ETW), което софтуерът може да използва за събиране на данни за системната активност.

Той също така се опитва да скрие своите файлове: според информацията, когато се правят определени заявки за файлове, драйверът връща дескриптор (handle) към легитимния процес calc.exe вместо към заявения зловреден файл.

Буткитът доставя и зловреден софтуер в потребителски режим (user-mode) за шпионаж. Единият зловреден код представлява троянски кон за отдалечен достъп (RAT), който може да зарежда допълнителен .NET код и да използва Google Drive, OneDrive или Yandex.Disk за комуникация за командване и управление (C2).

Другият, наречен OxiDLLRunner от изследователите, декриптира файл с име v8_context_snapshot.bin и изпълнява зловреден код, написан на Rust, който се свързва с докладван домейн за командване и управление.

Докладът свързва активността с APT41 с умерена увереност, базирайки се на припокривания с по-рано докладвана активност и споделени технически детайли. Тази оценка не представлява окончателно приписване на авторството.

Защо обновените системи все още са изложени на риск

Проблемът не се свежда просто до липсата на обновления за Windows на атакуваните компютри. Securelist посочва, че защитата срещу Baton Drop зависи от оттеглянето на доверието към сертификата „Windows Production PCA 2011“, използван за подписване на уязвимите UEFI компоненти.

Инсталирането на обновяване и прилагането на това оттегляне са отделни стъпки в описания от изследователите процес. Указанията на Microsoft за CVE-2023-24932 също описват множество стъпки за внедряване на защитите на Secure Boot, включително обновяване на сертификати, мениджъри за зареждане (boot managers) и списъка за оттегляне на UEFI.

Техните инструкции предупреждават, че блокирането на по-стари компоненти за зареждане може да засегне носителите за възстановяване и други опции за стартиране, така че администраторите трябва да тестват промените и да подготвят опции за възстановяване, преди да ги приложат масово. Вижте насоките на Microsoft за оттегляне в Secure Boot.

Разликата има значение, тъй като Windows може да докладва, че обновленията са инсталирани, дори когато списъкът със забранени подписи във фърмуера все още не е бил обновен по предвидения начин.

Securelist съобщава, че изтичането на валидността на сертификата на 19 октомври 2026 г. само по себе си не спира зареждането на уязвимите двоични файлове; сертификатът трябва да бъде блокиран чрез съответния механизъм за оттегляне.

Следователно администраторите трябва да проверят конфигурацията на Secure Boot и състоянието на оттегляне на своите устройства, следвайки текущите инструкции на Microsoft и отчитайки нуждите на организацията от първоначално зареждане и възстановяване.

BlackX не е първият буткит, повдигащ въпроси относно доверието в стари компоненти за зареждане. Cybersecurity News по-рано отрази BlackLotus и как техниката за понижаване на версията (downgrade) може да остави устройство с Windows уязвимо въпреки актуалния му статус.

Този контекст помага да се обясни защо защитата на Secure Boot зависи от повече от видимия статус на обновленията на Windows. Основният урок за защитниците е да потвърдят, че защитите на Secure Boot са активни във фърмуера, а не само че са инсталирани обновления за Windows.

Организациите трябва да прегледат насоките за внедряване на Microsoft, да проверят дали необходимите оттегляния са влезли в сила и да проверят носителите за зареждане и възстановяване за съвместимост.

Тъй като BlackX се инсталира, след като атакуващите са придобили административен достъп, екипите трябва също да разследват подозрителна административна активност и промени, свързани със стартирането, както и да преглеждат сигналите от крайните точки за признаци на манипулиране на мониторинга за сигурност.

Индикатори за компрометиране (IoCs):-

Забележка: IP адресите и домейните са умишлено деактивирани (defanged, напр. [.]), за да се предотврати случайно разрешаване на адреси или създаване на хипервръзки. Възстановявайте функционалността им само в рамките на контролирани платформи за анализ на заплахи като MISP, VirusTotal или вашата SIEM система.