Исследователь под ником Nightmare-Eclipse выложил рабочий прототип инструмента YellowKey. Он получает командную строку на зашифрованном BitLocker разделе — без ключа восстановления, без пин-кода, через обычную флешку и стандартную среду восстановления Windows. Атака работает только против конфигурации TPM-only, которая в корпоративных сетях встречается чаще, чем хотелось бы.
Как проверить, уязвима ли ваша машина
Открываете командную строку с правами администратора и вводите:
manage-bde -status C:
В выводе смотрите на строку Key Protectors. Если там написано только TPM — машина уязвима к этой атаке. Никакого пин-кода система не запросит при старте, TPM отдаст ключ автоматически после проверки цепочки загрузки.
Для проверки парка через PowerShell удобно использовать Get-BitLockerVolume в связке с Invoke-Command по списку хостов домена — получите сводную таблицу по всем машинам за один прогон. Если в вашей сети сотня ноутбуков и вы никогда целенаправленно не настраивали пин-коды — почти наверняка большинство из них сейчас в этом состоянии.
TPM-only выбирают не из беспечности. При развёртывании на сотни машин добавление пин-кода означает отдельную процедуру передачи кода каждому пользователю, хранение этих кодов, звонки в helpdesk от людей, которые забыли цифры после обновления. Это реальные операционные расходы, и многие организации осознанно идут на компромисс. YellowKey делает этот компромисс более дорогим.
Что именно делает YellowKey и почему это работает
Атака не взламывает шифрование — это важно понять сразу. AES-256 здесь вообще не при чём. Вместо этого используется механизм транзакций CLFS (Common Log File System) и то, как среда восстановления WinRE обрабатывает подключённые диски.
На флешке создаётся путь System Volume Information\FsTx с заранее подготовленными журналами транзакций CLFS. Флешку вставляют в выключенный компьютер и загружают WinRE — через Shift+Restart или напрямую с раздела восстановления.
Дальше происходит следующее: WinRE при старте сканирует все подключённые тома в поисках журналов транзакций. Библиотека fstx.dll находит журнал на флешке и воспроизводит записанные в нём операции — это штатное поведение, которое годами использовалось для восстановления повреждённых файловых систем. Через кросс-томные транзакции атакующий переписывает файл winpeshl.ini на разделе с образом восстановления. Вместо recenv.exe при следующем старте WinRE запускается cmd.exe.
TPM в этот момент делает именно то, для чего предназначен: проверяет цепочку загрузки, не находит нарушений — образ WinRE подписан Microsoft и не изменился — и отдаёт ключ. Среда восстановления считается доверенной, диск разблокируется, и атакующий получает командную строку с доступом к содержимому.
Разработчики механизма транзакций не закладывали в него проверку источника журналов. Логика была другой: если система видит незавершённую транзакцию, она должна её завершить. Откуда пришёл журнал — с системного раздела или с подключённой флешки — значения не имело, потому что никто не проектировал этот компонент с расчётом на то, что кто-то принесёт флешку с заготовленными метаданными.
Почему Secure Boot здесь не помогает
Secure Boot проверяет цифровые подписи компонентов до того, как они получают управление. Образ WinRE подписан Microsoft — проверка проходит. Вся манипуляция происходит уже внутри запущенной и верифицированной среды, на уровне файловой системы. Secure Boot к этому моменту уже отработал своё.
Теоретически регистры PCR в TPM должны фиксировать изменения конфигурации загрузки. На практике атака не трогает ядро и загрузчик — она меняет конфигурационный файл внутри легитимного образа. Значения PCR остаются в пределах ожидаемого диапазона, TPM не видит причин отказывать.
Патча от Microsoft на момент написания нет. Исходный код WinRE закрыт.
Настройка пин-кода
Опубликованная версия атаки работает против TPM-only. Добавление пин-кода убирает автоматическую выдачу ключа — даже если атакующий подменит точку входа, до содержимого диска он не доберётся без кода.
Через групповую политику: Конфигурация компьютера → Административные шаблоны → Компоненты Windows → Шифрование дисков BitLocker → Настроить использование дополнительного режима проверки при запуске. Включаем параметр, устанавливаем требование пин-кода.
После применения политики на конкретной машине:
manage-bde -protectors -add C: -tpandstartuppin
Nightmare-Eclipse упоминает, что у него есть непубликованный вариант обхода и для конфигурации с пин-кодом, но деталей не раскрывает. Насколько это реально — неизвестно. Пин-код точно переводит атаку в другую категорию сложности: вместо физического доступа нужно ещё знать или угадать код.
Радикальный вариант — отключить WinRE полностью:
reagentc.exe /disable
После этого стандартные комбинации для входа в среду восстановления перестают работать. Вместе с ними перестают работать и штатные инструменты диагностики. Если машина не загрузится — понадобится внешний загрузочный носитель. Для организаций, у которых есть процедура работы с такими случаями, это приемлемо. Для остальных — дополнительная головная боль.
Что делать, когда ноутбук уезжает в сервис
Антивирус и мониторинг сети не увидят то, что происходит до загрузки ОС. Логи будут пустыми. Обнаружить факт атаки постфактум сложно — артефакты на флешке могут быть удалены автоматически.
Если машина уходит в сервис или просто оказывается вне физического контроля: временно заблокируйте учётную запись пользователя в Active Directory — даже если атакующий получит командную строку, войти в домен он не сможет. Кэшированные токены лучше заранее сбросить. Данные, которые нельзя потерять, не должны лежать только локально — сетевое хранилище с MFA здесь надёжнее любых настроек BitLocker.
