Статья UEFI буткит и защита Secure Boot: разбор BlackLotus, CosmicStrand и атак на цепочку загрузки

Когда привыкаешь работать на уровне ring 0, кажется - глубже только голое железо. А потом обнаруживаешь, что между последней инструкцией ядра и первым тактом процессора лежит целый пласт кода, который большинство пентестеров никогда не трогали: UEFI firmware, DXE-драйверы, загрузчик ОС и EFI System Partition. Именно там в последние годы прочно обосновались буткиты - малварь, которая получает контроль ещё до инициализации операционной системы (полную классификацию по уровням привилегий, включая firmware-руткиты, собрал обзор техник руткитов и матрица обнаружения). Ниже ОС, ниже EDR, ниже всего, что ты привык мониторить.

В 2023 году ESET опубликовала подробный анализ BlackLotus - первого публично задокументированного буткита, который обходит UEFI Secure Boot на полностью обновлённой Windows 11. Чуть раньше «Касперский» описал CosmicStrand, живущий прямо в SPI-флеше материнской платы. Два семейства, две принципиально разные точки входа, одна цель - persistence ниже уровня ОС, невидимый для классических EDR.

Здесь - практический разбор: где именно в цепочке загрузки находятся точки атаки, как BlackLotus и CosmicStrand их эксплуатируют, и что ты можешь сделать руками, чтобы обнаружить или предотвратить компрометацию на уровне прошивки. Все команды и инструменты проверены на лабораторном стенде с QEMU/OVMF и на физическом железе.

Цепочка загрузки UEFI: где именно живут буткиты​

Прежде чем препарировать конкретную малварь, нужно понимать boot flow. UEFI разделяет загрузку на несколько фаз - по спецификации UEFI Forum последовательность такая:

1. SEC (Security Phase) - процессор выходит из reset vector, переключается из real mode в protected mode, инициализирует временную RAM через CPU cache.
2. PEI (Pre-EFI Initialization) - настройка контроллера памяти, включение DRAM, инициализация чипсета.
3. DXE (Driver Execution Environment) - самая длинная фаза: загрузка всех DXE-драйверов, инициализация остального оборудования, настройка SMM, создание таблиц BootServices и RuntimeServices.
4. BDS (Boot Device Selection) - выбор загрузочного устройства, запуск загрузчика ОС из EFI System Partition.
5. TSL (Transient System Load) - передача управления загрузчику ОС (bootmgfw.efi → winload.efi).

Каждый переход между фазами включает проверку подписи следующего компонента - это chain of trust, реализуемая UEFI Secure Boot. Root-of-trust сидит в platform initialization firmware; при включённом Intel Boot Guard - в аппаратной логике, которую программно не тронуть.

Буткиты атакуют разные звенья цепочки. Классификация по точке внедрения (на основе анализа Binarly):

Буткит	Точка внедрения	Тип компонента	Переживает переустановку ОС	Переживает замену диска
BlackLotus	ESP (EFI System Partition)	UEFI Application	Да	Нет
CosmicStrand	SPI Flash (DXE-драйвер)	DXE Driver	Да	Да
MoonBounce	SPI Flash (DxeCore)	Modified DxeCore	Да	Да
ESPecter	ESP	UEFI Application	Да	Нет
Bootkitty	ESP (замена GRUB)	UEFI Application	Да	Нет

Принципиальная разница: ESP-буткиты (BlackLotus, ESPecter) живут на FAT32-разделе диска - теоретически до них можно добраться. SPI-буткиты (CosmicStrand, MoonBounce) записаны в микросхему прошивки на материнской плате. Переустановка ОС, замена жёсткого диска - им всё равно. Они уже дома.

BlackLotus буткит: обход Secure Boot через CVE-2022-21894​

Суть атаки​

BlackLotus - первый публично подтверждённый in-the-wild UEFI буткит, способный обойти Secure Boot на полностью обновлённых системах Windows 11. По данным ESET (Martin Smolár, WeLiveSecurity, март 2023), он продавался на подпольных форумах с октября 2022 года за $5000. Пять тысяч баксов - и Secure Boot перестаёт существовать.

Ключевой механизм - эксплуатация CVE-2022-21894 (Secure Boot Security Feature Bypass Vulnerability). По NVD:

• CVSS: 4.4 (MEDIUM)
• Вектор: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N
• CWE: CWE-863 (Incorrect Authorization)

Разберём вектор: атака локальная (AV:L), требует высоких привилегий (PR:H), действие пользователя не нужно (UI:N), зато полный контроль над целостностью (I:H). Формально CVSS-оценка «средняя» - и вот тут начинается самое интересное. PR:H значит, что атакующему нужен admin/SYSTEM. Но если ты его уже получил через фишинг, BYOVD или эксплойт ядра, эта «средняя» уязвимость открывает дверь к абсолютной persistence. Лично я считаю, что CVSS здесь сильно недооценивает реальный импакт - контекст атаки всё меняет.

Microsoft выпустила патч в январе 2022 года, но вот незадача: подписанные уязвимые бинарники не были добавлены в UEFI revocation list (dbx). BlackLotus приносит с собой собственные копии легитимных, но уязвимых загрузчиков - классическая Downgrade Attack (T1562.010, Defense Evasion по MITRE ATT&CK). Патч есть, а толку нет.

Цепочка установки​

По анализу ESET, установка BlackLotus идёт в несколько этапов:

Шаг 0 - Инициализация. Инсталлятор проверяет локаль системы. Если ru-RU, uk-UA, be-BY, hy-AM, kk-KZ, ro-MD или ru-MD - установка прерывается. Типичный маркер пост-советского crimeware - «своих не трогаем».

Шаг 1 - Развёртывание файлов. На ESP размещаются: уязвимый подписанный загрузчик Windows, самоподписанный MOK (Machine Owner Key), вспомогательные файлы.

Шаг 2 - Отключение HVCI. Hypervisor-protected Code Integrity вырубается до перезагрузки, чтобы убрать проверку целостности кода на уровне гипервизора.

Шаг 3 - Отключение BitLocker. Снимается защита тома - буткиту нужен доступ к загрузочным компонентам без шифрования.

Шаг 4 - Эксплуатация CVE-2022-21894 и установка persistence. Через уязвимый загрузчик (техника «Baton Drop») буткит регистрирует собственный MOK в NVRAM. При следующей загрузке Secure Boot считает буткит доверенным. Code Signing Policy Modification (T1553.006) в чистом виде.

Шаг 5 - После перезагрузки. Буткит стартует как загрузчик, разворачивает kernel-mode драйвер и HTTP-загрузчик (работает в контексте winlogon.exe). Драйвер защищает файлы буткита на ESP от удаления - попытка закрыть файловые хэндлы приводит к BSOD. Грубо, но работает.

Что отключает BlackLotus​

После установки BlackLotus вырубает:

• Windows Defender - деактивация основного процесса
• HVCI - отключение гипервизорной проверки целостности кода
• BitLocker - снятие защиты тома
• UAC - обход контроля учётных записей

По сути, полностью защищённая Windows 11 превращается в открытую площадку, где атакующий грузит произвольные компоненты в kernel-mode и user-mode. Все эти буквы - HVCI, BitLocker, UAC - оказываются красивым фантиком.

CosmicStrand малварь: буткит в SPI-флеше​

Если BlackLotus - буткит «на диске», то CosmicStrand - firmware implant, записанный в SPI flash материнской платы. Разница между ними определяет всё: подход к обнаружению, удалению и вообще шансы на успех.

Точка внедрения​

CosmicStrand модифицирует DXE-драйвер в прошивке UEFI. При каждой загрузке скомпрометированный драйвер получает управление на фазе DXE - задолго до того, как Secure Boot проверяет загрузчик ОС. Почему? Потому что DXE-код - часть самой прошивки и считается доверенным по определению. Secure Boot защищает от внешних угроз, а тут враг уже внутри крепости.

По данным Kaspersky и Binarly, CosmicStrand использует hooking таблицы BootServices: подменяет указатели функций на собственные обработчики. Для поиска функции OslArchTransferToKernel в памяти применяется 4-байтовая сигнатура 0x41106A56 - буткит сканирует память, находит нужное место и подставляет inline hook, перехватывая момент передачи управления ядру Windows.

Это техника System Firmware (T1542.001, Persistence / Defense Evasion) - persistence непосредственно в прошивке.

Почему это опаснее ESP-буткитов​

Критерий	BlackLotus (ESP)	CosmicStrand (SPI Flash)
Переживает замену диска	Нет	Да
Переживает переустановку ОС	Да	Да
Обнаружение стандартными AV	Теоретически возможно (FAT32)	Практически невозможно
Требует физического доступа для удаления	Нет	Часто да (перепрошивка)
Сложность установки	Средняя (нужен admin)	Высокая (нужен доступ к SPI)

Чтобы убить CosmicStrand, нужна перепрошивка UEFI с чистым образом от производителя. Переустановка Windows, форматирование диска, замена SSD - ничего из этого не поможет. Малварь живёт в чипе на плате - и ей плевать на твои диски.

Атаки на цепочку загрузки: общие техники​

Binarly провели сравнительный анализ нескольких семейств и выявили общие паттерны поведения. Для тех, кто строит generic-детектирование - это золото.

Сброс бита Write Protect в CR0​

Все современные буткиты (CosmicStrand, ESPecter, BlackLotus, MoonBounce) сбрасывают бит WP в регистре CR0. Снимают защиту записи с read-only страниц памяти, после чего спокойно патчат PE-заголовки ядра, меняют entry point, правят права секций. В легитимных UEFI-приложениях такое поведение - редкость. Если видишь сброс WP в CR0 на этапе загрузки - это красный флаг.

Shellcode-подобный парсинг PE​

Буткиты сами парсят PE-заголовки загруженных образов (ядро Windows, загрузчик) - без штатных API прошивки. Ручной обход таблицы экспорта, поиск функций по хешам имён - поведение, знакомое любому, кто анализировал шеллкод. Binarly отмечает: в легитимных UEFI-приложениях такой паттерн практически не встречается.

Inline hooking OslArchTransferToKernel​

Четыре из шести исследованных Binarly буткитов (MoonBounce, CosmicStrand, ESPecter, BlackLotus) перехватывают функцию OslArchTransferToKernel - критическую точку передачи управления от загрузчика ядру. Но каждый использует свою сигнатуру поиска и свои инструкции для патча. Так что единую сигнатуру написать не получится - придётся ловить по поведению.

UEFI rootkit анализ: практическое обнаружение​

Ладно, хватит теории. Переходим к тому, ради чего вы это читаете - конкретные команды и инструменты.

Проверка состояния Secure Boot​

Стандартная проверка через mokutil недостаточна - она показывает состояние, которое ОС считает актуальным, а буткит может его подделать. Проверяем из нескольких источников:

# Проверка из ОС (может быть скомпрометирована буткитом)
mokutil --sb-state

# Проверка через UEFI-переменные напрямую
efivar -l | grep SecureBoot
efivar -p -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-SecureBoot

# Чтение dbx (revocation list) - проверяем, обновлён ли
efivar -p -n d719b2cb-3d3a-4596-a3bc-dad00e67656f-dbx | head -20

Если mokutil --sb-state говорит «SecureBoot enabled», а efivar для SecureBoot возвращает 00 - поздравляю, это прямой индикатор компрометации. Буткит врёт операционке, а та радостно передаёт враньё тебе.

Аудит конфигурации UEFI с CHIPSEC​

CHIPSEC - open-source фреймворк от Intel для аудита безопасности прошивки. На физическом железе он позволяет проверить критические настройки защиты SPI-флеша:

# Установка (требует Linux, kernel headers, доступ к /dev/mem)
pip install chipsec

# Проверка защиты записи SPI-флеша
sudo chipsec_main -m common.spi_lock

# Проверка защиты BIOS Region
sudo chipsec_main -m common.bios_wp

# Проверка SMRAM (защита System Management RAM)
sudo chipsec_main -m common.smrr

# Полный аудит безопасности прошивки
sudo chipsec_main

Что искать в выводе:

• common.spi_lock - FAILED означает, что SPI-флеш можно перезаписать программно. Дверь для имплантов типа CosmicStrand открыта.
• common.bios_wp - проверяет биты BWE, BLE, PRx. Если защита не активирована - прошивку можно модифицировать прямо из ОС. На одном тесте я видел FAILED на обоих модулях у свежего серверного железа из коробки. Вендор просто не включил защиту.

Извлечение и анализ прошивки​

Чтобы найти вредоносные DXE-драйверы, нужно снять дамп прошивки и разобрать каждый модуль:

# Дамп прошивки через CHIPSEC
sudo chipsec_util spi dump firmware.bin

# Извлечение модулей через UEFITool (GUI) или UEFIExtract (CLI)
UEFIExtract firmware.bin all

# Поиск аномалий в DXE-модулях через binwalk
binwalk -e firmware.bin

# Быстрая проверка энтропии (зашифрованные/упакованные модули подозрительны)
binwalk -E firmware.bin

В UEFITool ищите DXE-драйверы с нестандартными GUID, аномально большим размером или модули, не совпадающие с эталонным образом прошивки от производителя. Если модуль есть в дампе, но его нет в эталоне - копайте глубже.

Мониторинг EFI System Partition​

ESP-буткиты (BlackLotus, ESPecter) оставляют артефакты на FAT32-разделе. Вот как их искать:

# Монтирование ESP
sudo mount /dev/sda1 /mnt/esp

# Вычисление хешей всех EFI-файлов
find /mnt/esp -name "*.efi" -exec sha256sum {} \;

# Сравнение с эталонными хешами загрузчиков Microsoft
# bootmgfw.efi должен совпадать с подписанной версией из текущего обновления

# Поиск подозрительных файлов (BlackLotus размещает ~80 КБ бинарник)
find /mnt/esp -name "*.efi" -size +50k -size -100k -ls

# Проверка подписей EFI-файлов
pesign --show-signature -i /mnt/esp/EFI/Microsoft/Boot/bootmgfw.efi

По данным ESET, файлы BlackLotus на ESP имеют размер около 80 КБ. Отдельно проверяйте, не появились ли в NVRAM неизвестные MOK-ключи - BlackLotus регистрирует собственный сертификат для обхода Secure Boot.

UEFI Memory Forensics​

Исследователи (публикация на arXiv, 2025) разработали фреймворк для анализа памяти UEFI на этапе pre-OS. Два компонента:

• UefiMemDump - DXE-драйвер или UEFI shell-приложение для снятия дампа памяти во время работы прошивки, до передачи управления ОС.
• UEFIDumpAnalysis - набор модулей анализа: обнаружение hooking указателей функций в таблицах BootServices/RuntimeServices, детектирование inline hooking, извлечение загруженных UEFI-образов.

Proof-of-concept демонстрирует обнаружение CosmicStrand и Glupteba по модификации указателей в таблицах сервисов. Фреймворк open-source - первый инструмент подобного рода для below-OS memory forensics. Штука сырая, но рабочая.

Secure Boot уязвимости: проблема revocation​

Ключевая проблема, которую эксплуатирует BlackLotus, - не сама CVE-2022-21894, а сломанный механизм отзыва. Microsoft выпустила патч, но не добавила уязвимые подписанные загрузчики в dbx (UEFI revocation list). Причина по данным ESET: уязвимость затрагивает сотни легитимных загрузчиков, которые до сих пор используются. Массовый отзыв может привести к невозможности загрузки на миллионах машин.

Это системная проблема Secure Boot, и она выглядит как замкнутый круг:

1. Microsoft подписывает сторонние загрузчики (shim для Linux, загрузчики OEM-вендоров) своим UEFI CA ключом.
2. Если любой из этих загрузчиков оказывается уязвимым - его нужно добавить в dbx.
3. Добавление в dbx сломает загрузку всех систем, использующих этот загрузчик.
4. Поэтому отзыв не происходит - и уязвимость остаётся эксплуатируемой.

Получается забавно: механизм защиты не работает, потому что его боятся включить. На заборе написано «Secure Boot», а по факту - дырявый забор.

Аналогичная история с LogoFAIL - уязвимостью в библиотеках обработки BMP-изображений внутри UEFI-прошивок. По данным Binarly Research, буткит Bootkitty использовал LogoFAIL для добавления своего самоподписанного сертификата в список доверенных, обходя Secure Boot без ручного вмешательства оператора. Уязвимость затрагивала прошивки ноутбуков Acer, HP, Fujitsu и Lenovo. Через картинку с логотипом. Серьёзно.

Защита от буткитов: что реально работает​

Intel Boot Guard​

Единственный механизм, который переносит root-of-trust в неизменяемое оборудование. При включённом Boot Guard ключи верификации зашиты в фьюзы процессора - программная модификация невозможна. По данным Binary Defense, на момент написания не существует in-the-wild буткитов, обходящих Boot Guard. Были утечки ключей, но рабочих эксплойтов в дикой природе не зафиксировано.

Как проверить:

# Через CHIPSEC
sudo chipsec_main -m common.secureboot.variables
sudo chipsec_main -m common.bios_ts

Обновление dbx​

Регулярно обновляйте UEFI revocation list. Microsoft публикует обновления dbx через Windows Update, но на Linux это нужно делать вручную:

# Загрузка актуального dbx от UEFI Forum
# https://uefi.org/revocationlistfile

# Применение через fwupd
fwupdmgr get-updates
fwupdmgr update

# Или вручную через efi-updatevar (осторожно - можно окирпичить загрузку!)
# efi-updatevar -f dbx-update.bin dbx

Мониторинг ESP на изменения​

Настройте регулярное сканирование EFI System Partition. Любое изменение файлов в /boot/efi/EFI/ вне штатного обновления ОС - повод для расследования:

# Создание эталонного снимка
find /boot/efi -type f -exec sha256sum {} \; > /root/esp_baseline.txt

# Периодическая проверка (cron)
find /boot/efi -type f -exec sha256sum {} \; | diff /root/esp_baseline.txt -

Measured Boot и TPM Attestation​

TPM (Trusted Platform Module) фиксирует хеши каждого компонента цепочки загрузки в PCR-регистрах (Platform Configuration Registers). При наличии remote attestation сервера можно автоматически обнаружить подмену загрузчика:

# Чтение текущих значений PCR
tpm2_pcrread sha256:0,1,2,3,4,5,6,7

# PCR[0] - firmware code
# PCR[4] - загрузчик
# PCR[7] - Secure Boot state

Изменение PCR[4] или PCR[7] между штатными загрузками без обновления системы - прямой индикатор компрометации загрузчика.

Таблица маппинга ATT&CK для буткит-атак​

Техника MITRE ATT&CK	Тактика	Применение в буткитах
Bootkit (T1542.003)	Persistence, Defense Evasion	BlackLotus, ESPecter, Bootkitty
System Firmware (T1542.001)	Persistence, Defense Evasion	CosmicStrand, MoonBounce
Rootkit (T1014)	Defense Evasion	Kernel-mode драйвер BlackLotus
Code Signing Policy Modification (T1553.006)	Defense Evasion	Регистрация MOK в BlackLotus
Downgrade Attack (T1562.010)	Defense Evasion	Подмена загрузчиков уязвимыми версиями
Compromise Hardware Supply Chain (T1195.003)	Initial Access	Заражение прошивки на этапе производства
Inhibit System Recovery (T1490)	Impact	Отключение BitLocker в BlackLotus

Практический чеклист: обнаружение UEFI буткитов​

Пошаговый алгоритм для проверки системы на firmware-угрозы - делай раз, делай два, делай три:

Шаг 1 - Проверь конфигурацию Secure Boot. Сравни вывод mokutil --sb-state с прямым чтением UEFI-переменных через efivar. Проверь список установленных MOK-ключей через mokutil --list-enrolled. Неизвестные сертификаты - красный флаг.

Шаг 2 - Аудит защиты SPI-флеша. Запусти chipsec_main и проверь модули spi_lock, bios_wp, smrr. Любой FAILED означает, что прошивку можно перезаписать программно - система уязвима для SPI-имплантов.

Шаг 3 - Проверь целостность ESP. Смонтируй раздел, вычисли хеши всех .efi-файлов, сравни с эталонными значениями. Обрати внимание на файлы размером 50-100 КБ с нестандартными именами.

Шаг 4 - Сними дамп прошивки. chipsec_util spi dump, затем разбери дамп через UEFITool или UEFIExtract. Сравни GUID и количество DXE-модулей с эталонным образом от производителя.

Шаг 5 - Проверь PCR-значения TPM. Если в организации настроена remote attestation - сравни текущие PCR с базовыми значениями. Без attestation - зафиксируй PCR после чистой установки и отслеживай расхождения.

Шаг 6 - Проверь binwalk-энтропию модулей прошивки. Аномально высокая энтропия отдельных DXE-модулей может указывать на зашифрованную или упакованную вредоносную нагрузку.

Заключение​

UEFI буткиты - не теоретическая страшилка из презентаций. BlackLotus продаётся за $5000 и работает на актуальных системах. CosmicStrand показал, что SPI-флеш - тоже не безопасная зона. По данным Positive Technologies, 27 семейств буткитов применяются в реальных атаках, 14 из них - инструменты APT-группировок.

Классический периметр «ОС + EDR» не покрывает firmware-уровень. Точка. Защита Secure Boot критически зависит от актуальности revocation list (dbx), целостности SPI-флеша и наличия аппаратного root-of-trust (Intel Boot Guard). Проверка mokutil --sb-state - необходимый, но недостаточный шаг: буткит уровня BlackLotus подделает ответ ОС и сохранит иллюзию безопасности.

Запустите CHIPSEC на своём железе, проверьте целостность ESP, внедрите TPM attestation. Самый глубокий persistence всегда живёт там, куда большинство защитников никогда не заглядывает. Может, пора заглянуть?