12 мая 2026 года исследователь, известный под никами Chaotic Eclipse и Nightmare-Eclipse, выложил на GitHub рабочий PoC для уязвимости нулевого дня в Windows под названием YellowKey. Эксплойт позволяет выйти в командную строку и получить доступ к зашифрованному BitLocker системному диску любому, у кого есть физический доступ к компьютеру с Windows 11, Windows Server 2022 или Windows Server 2025. Без пароля, ключа восстановления или сложного оборудования для перехвата данных TPM. Достаточно USB-накопителя и комбинации клавиш во время перезагрузки.

Профильная пресса подхватила тему мгновенно. Хакерское сообщество — тоже. А вот в криминалистическом сообществе, как ни странно, новость прошла практически незамеченной. И это серьёзная ошибка. Если в хранилище улик пылится изъятый ноутбук с BitLocker, который числится «холодным» вещественным доказательством, новый эксплойт даёт шанс на извлечение данных максимально простым и быстрым способом. Окно возможностей открыто нараспашку.

В этой статье мы разберём, как именно BitLocker защищает системный раздел, как YellowKey обходит эту модель защиты, как криминалист может использовать уязвимость в работе и что на самом деле может стоять за утверждением исследователя об уязвимости модели защиты TPM+PIN.

Освежим в памяти: BitLocker и шифрование устройств

BitLocker — встроенный в Windows механизм шифрования тома. Содержимое диска шифруется алгоритмом AES (на современных установках по умолчанию — 128-битным ключом в режиме XTS) ключом FVEK (Full Volume Encryption Key, ключ шифрования полного тома). Сам FVEK хранится в зашифрованном виде, и оборачивает его другой ключ — VMK (Volume Master Key, главный ключ тома). Именно VMK разблокирует любой из настроенных модулей защиты: пароль, ключ восстановления, смарт-карту, файл-ключ на USB-устройстве или TPM — отдельно либо в комбинации с PIN-кодом, ключом запуска или с тем и другим.

Криминалистическую картину на современных компьютерах с Windows меняет не классический BitLocker, который администраторы вручную настраивают на корпоративных ноутбуках. Речь идёт о функции «Шифрование устройств» (Device Encryption) — автоматическом варианте, который Microsoft включает на любом относительно современном устройстве, соответствующем определённым требованиям, причём на любой редакции Windows, включая Home. Пользователю не нужно ничего делать; ему даже знать о шифровании необязательно. Если устройство пришло с предустановленной Windows 11 и пользователь вошёл в систему под учётной записью Microsoft — системный диск почти наверняка зашифрован.

Ключ восстановления в этом сценарии система загружает в учётную запись Microsoft того пользователя, который первым вошёл на устройство с правами администратора. Если человек не знает про шифрование — про ключ восстановления он знает ещё меньше. А если он потом переключился на локальную учётную запись, сменил логин Microsoft Account или просто не помнит, какой именно адрес Outlook или Hotmail использовал при начальной настройке, — ключ для него практически потерян.

Для специалистов по восстановлению данных этот вариант шифрования давно стал привычной головной болью. Клиент приносит ноутбук, понятия не имея, что диск был зашифрован; ключа восстановления у него нет. Восстановление невозможно. YellowKey не закрывает все варианты проблемы (для его работы нужно, чтобы компьютер — именно тот, на котором был зашифрован диск, — хотя бы загружался), но в любом случае меняет расклад кардинально.

Защита TPM: как это должно работать

Чтобы понять, как именно YellowKey обходит защиту (стойкое шифрование! AES! длинные ключи!), стоит освежить, как работает шифрование в Windows. Подробный разбор есть в нашей статье 2021 года — Модули TPM: что нужно знать эксперту-криминалисту. Статья по-прежнему актуальна, здесь же — краткий пересказ.

В конфигурации по умолчанию используется тип защиты «только TPM» (её и использует «Шифрование устройств»). В этом режиме ключ VMK запечатан внутри модуля TPM и привязан к набору регистров PCR (Platform Configuration Registers, регистры конфигурации платформы). Во время загрузки на каждой стадии последовательно формируется цепочка доверия на основе значений регистров PCR:  все компоненты цепочки связаны между собой и любое нарушение приведёт к изменению содержимого PCR регистров. Если цепочка совпадает с теми значениями, которые были в момент включения BitLocker, модуль TPM отдаёт ключ VMK менеджеру загрузки. Если в цепочке хоть что-то изменилось, TPM отказывается выдавать ключ, и пользователь видит на экране компьютера запрос на ввод ключа восстановления.

Здесь и зарыта собака: если цепочка доверия уже прошла проверку, TPM выдаст VMK автоматически, без какого-либо взаимодействия с пользователем. В этом и смысл «Шифрования устройств» — легитимный владелец вообще не должен видеть никаких запросов; всё работает абсолютно прозрачно. TPM передаёт ключ, Windows монтирует зашифрованный том, и жизнь идёт своим чередом. Подразумевается, что внутри самой доверенной цепочки загрузки не может произойти никаких изменений, которые останутся незамеченными, и чисто технически это всё ещё так.

Конфигурация TPM+PIN, к которой мы вернёмся чуть ниже, добавляет одну деталь: теперь TPM дополнительно требует от пользователя ввести правильный PIN-код (по умолчанию — минимум 6 цифр) перед тем, как отдать VMK. Цепочка доверия работает по-прежнему, но добавляется лишний шаг — ввод PIN-кода пользователем. Такой способ традиционно рекомендовали для защиты корпоративных устройств с чувствительными данными.

Уязвимость YellowKey

YellowKey — это уязвимость в среде восстановления Windows (Windows Recovery Environment, WinRE), благодаря которой атакующий получает командную строку с доступом к зашифрованному BitLocker системному диску. Подверженный уязвимости компонент можно найти исключительно в образе WinRE; исследователь обращает внимание на то, что компонент с тем же именем есть и в обычной установке Windows — но без функционала, который позволяет обойти защиту. Эта асимметрия наводит на мысль, что перед нами не случайная ошибка, а намеренно добавленный в среду код; подробнее об этом мы поговорим в конце.

Кратко: что такое Windows RE и почему это не Windows PE. Windows RE (Windows Recovery Environment, среда восстановления Windows) — это встроенная в Windows минимальная операционная среда, в которую система уходит при сбое загрузки, серьёзной ошибке или по запросу пользователя через меню «Перезагрузка». Внутри неё работают штатные инструменты восстановления: «Восстановление при загрузке», возврат к точке восстановления, сброс системы и командная строка. Образ Windows RE хранится в виде файла winre.wim на отдельном служебном разделе восстановления и при необходимости разворачивается на виртуальном диске в оперативной памяти. В русскоязычных публикациях её регулярно путают с Windows PE (Windows Preinstallation Environment, на которой, кстати, основан наш Elcomsoft System Recovery) — а это другая среда: она тоже основана на минимальном ядре Windows, но предназначена для развёртывания ОС, установки с нуля и обслуживания, не входит в установленную систему по умолчанию и распространяется отдельно. Уязвимость YellowKey касается именно Windows RE — той среды, которая лежит на каждом современном устройстве с Windows 11 и в которую попадают штатными средствами самой системы.

В зоне поражения — Windows 11 и Windows Server 2022/2025. Windows 10 на данный момент уязвимость не затрагивает. Несколько независимых исследователей, в том числе Will Dormann (Tharros Labs) и Kevin Beaumont, публично подтвердили работоспособность эксплойта.

Как это работает

Эксплойт использует ветку кода внутри WinRE, которая сканирует подключённые накопители на наличие журналов транзакций NTFS в конкретной папке System Volume Information\FsTx и воспроизводит всё, что там найдёт. Интересный момент, на который обратил внимание Will Dormann: воспроизведение журналов с одного тома может изменять содержимое другого тома. Подготовив правильное содержимое журнала, злоумышленник с помощью USB-накопители или файлов, записанных прямо в системный раздел EFI, заставляет WinRE переписать часть собственного образа восстановления на ранней стадии загрузки.

В опубликованном PoC результат такой: из образа WinRE удаляется файл winpeshl.ini. Именно winpeshl.ini указывает WinRE, как запустить интерфейс восстановления; без него WinRE откатывается на резервный вариант и запускает командную строку cmd.exe. Конкретная комбинация клавиш, удерживаемая во время загрузки, запускает выполнение этой ветки. Окно командной строки, которое появляется на экране, позволяет получить доступ к защищённому BitLocker системному тому, потому что к моменту входа в WinRE модуль TPM уже выдал VMK. С точки зрения TPM цепочка доверия не нарушена, а среда восстановления и должна иметь легитимный доступ к тому для выполнения своей задачи. Ошибка же в том, насколько тривиально этот доступ перенаправляется в командную строку.

Опубликованный репозиторий содержит всё, что нужно для применения уязвимости, и независимых подтверждений уже несколько. Подробности мы здесь повторять не будем, о них уже написали профильные издания.

Использование YellowKey в криминалистике

Для специалиста, у которого на руках — зашифрованный компьютер или ноутбук, процедура разбивается на три этапа: перезагрузка в среду восстановления Windows, получение командной строки и извлечение ключа восстановления BitLocker. Но сначала — несколько предварительных замечаний.

1. Процедура изменяет устройство. Воспроизведение журнала FsTx меняет содержимое образа WinRE, а после удаления winpeshl.ini на разделе восстановления устройство уже не находится в исходном состоянии. Сначала может иметь смысл снять образ диска с помощью аппаратного блокиратора записи или Elcomsoft System Recovery, зафиксировать контрольные суммы до и после. Эксплойт работает на загруженном устройстве, но образ изначального содержимого позволяет сохранить эталон.
2. Убедитесь, что на компьютере стоит ОС, подверженная уязвимости. Windows 10 — по крайней мере, пока — не затронута. Поддерживаются Windows 11, Server 2022 и Server 2025.
3. Процедура капризная. Требует точный тайминг — отмечено, что чисто отработать с первого раза получается редко. Помимо тайминга, эксплойт срабатывает не на каждом устройстве из списка затронутых — об этом см. оговорку про Trusted WIM Boot в конце раздела. Закладывайте время на повторные попытки и на ощутимый процент неудач.

Этап 1: перезагрузка в среду восстановления Windows

В первую очередь нужно попасть в среду восстановления Windows RE. Предварительно подготовьте USB-накопитель с папкой FsTx из репозитория YellowKey, разместив её по правильному пути внутри System Volume Information, и подключите к изъятому компьютеру до начала перезагрузки.

Способ, которым можно попасть в WinRE, зависит от состояния устройства.

• Если устройство заблокировано, но пользователь вошёл в систему (например, ноутбук изъяли включённым, в спящем режиме или в гибернации, и сейчас на нём отображается экран блокировки) — проще всего использовать перезагрузку с зажатой клавишей Shift. На экране блокировки нажмите кнопку питания в правом нижнем углу, удерживайте Shift и щёлкните «Перезагрузка». Устройство уйдёт в среду восстановления WinRE. По умолчанию этот способ работает на большинстве систем на руках обычных пользователей, но может быть заблокирован в корпоративных средах, где групповая политика скрывает пункты управления питанием с экрана блокировки (чаще всего — через политику «Удалить и запретить доступ к командам «Завершение работы», «Перезагрузка», «Спящий режим» и «Гибернация»»), в конфигурациях с «Назначенным доступом» или режимом киоска, на устройствах, управляемых через Intune или другой MDM, где администратор отключил кнопку питания на экране входа, либо везде, где её скрыли вручную локальной политикой. Если на экране блокировки нет кнопки питания, или если Shift+перезагрузка уводит устройство в обычную загрузку, а не в среду восстановления, переходите к «холодному» варианту ниже.
• Если устройство выключено (а это типичное состояние устройства, давно лежащего в хранилище улик), придётся вводить его в WinRE принудительно, через механизм автоматического восстановления Windows. Microsoft описывает процедуру в статье «Среда восстановления Windows»: включите устройство, затем удерживайте кнопку питания, чтобы выполнить аппаратное выключение до завершения загрузки Windows. Повторите дважды. На третьем включении Windows распознаёт две предыдущие неудачные попытки загрузки и сама уходит в среду восстановления. Способ надёжный, но не нейтральный с процессуальной точки зрения: принудительные выключения изменяют счётчик попыток в BCD, добавляют записи о «нечистых» завершениях в журнал событий, а в редких случаях могут привести к нарушениям в файловой системе. Зафиксируйте хэши до и после и задокументируйте процедуру в том виде, в каком вы её выполняли.

Этап 2: выход в командную строку

На этом этапе осуществляется переход из обычной оболочки восстановления в окно командной строки.

В момент, когда срабатывает переход в WinRE, каким бы способом он ни был запущен, отпустите все клавиши и сразу нажмите и удерживайте клавишу Ctrl. Удерживайте Ctrl до тех пор, пока на экране не появится окно командной строки. Если всё прошло удачно, то появившаяся оболочка получит прямой доступ на чтение к системному тому, защищённому BitLocker.

Тайминги имеют критическое значение. Многие исследователи сообщают, что чисто отработать удаётся не с первой попытки, поэтому после неудачи стоит повторить попытку. Каждая повторная попытка означает возврат к первому этапу, а на «холодном» устройстве это очередная серия принудительных прерываний загрузки.

Важная оговорка: эксплойт срабатывает не на каждом устройстве с совместимой ОС. Как только в WinRE появилась поддержка восстановления BitLocker, появился механизм под названием Trusted WIM Boot. Он сохраняет хэш образа WinRE.wim внутри блока метаданных FVE BitLocker (целостность этого блока защищена AES-CCM) и сверяет хэш во время загрузки среды восстановления. Когда воспроизведение FsTx-журнала в YellowKey меняет содержимое внутри образа WinRE, проверка хэша должна провалиться; в этом случае системный том остаётся заблокированным, а открывшаяся оболочка к зашифрованным данным доступа не получит. Сработает ли Trusted WIM Boot на конкретной машине, зависит от того, прописан ли ожидаемый хэш WIM в метаданных BitLocker этого устройства. На заметной доле ноутбуков хэш WIM в метаданных отсутствует — то есть, на них YellowKey сработает. Да других устройствах, где хэш WIM прописан в метаданных, эксплойт не сработает. Тем не менее, имеет смысл попробовать, понимая, что на части устройств доступа к зашифрованному тому не будет.

Этап 3: извлечение ключа восстановления через manage-bde

Когда командная строка запущена и том BitLocker доступен, имеет смысл не читать файлы с диска, а извлечь данные, которые позволят дешифровать исходный криминалистический образ лаборатории. Используйте для этого команду manage-bde.

Обратите внимание: в WinRE буквы дисков переназначаются — сама WinRE работает под буквой X:. Системный том чаще всего оказывается на C:, но может оказаться и на D:, или на другой букве — в зависимости от разметки. Поэтому последовательность такая:

manage-bde -status

В выводе найдите том со статусом Protection Status: Protection On и BitLocker Version: 2.0 — это и есть нужная вам буква диска. Затем:

manage-bde -protectors -get C:

(подставив ту букву, которую вы нашли). В выводе ищите модуль защиты Numerical Password. Это 48-значный ключ, разбитый на восемь групп по шесть цифр через дефис — это и есть ключ восстановления BitLocker. Сохраните его как есть: он годится и как пароль для разблокировки вручную, и в качестве ключа для Elcomsoft Forensic Disk Decryptor при дешифровке образа диска.

Отметим, что модуль Numerical Password создаётся в момент начальной настройки BitLocker независимо от того, какой основной модуль защиты используется на томе (TPM-only, TPM+PIN, пароль и так далее). Поэтому даже на устройстве с «Шифрованием устройств» в режиме TPM, где пользователь никогда не видел запроса ключа восстановления, этот модуль защиты всё равно присутствует — просто при его создании он был молча отправлен в учётную запись Microsoft первого пользователя-администратора компьютера. Его извлечение даёт устойчивый ключ, который переживёт любой последующий патч или замену оборудования. С ним на руках Elcomsoft Forensic Disk Decryptor дешифрует ранее снятый криминалистический образ или смонтирует его в виде виртуального диска для последующего анализа.

Дополнительные материалы:

• BitUnlocker: Leveraging Windows Recovery to Extract BitLocker Secrets | Microsoft Community Hub
• Загрузка файла образа Windows (WimBoot) — Win32 apps | Microsoft Learn
• Справочник по параметрам BitLocker — Configuration Manager | Microsoft Learn

Почему это важнее, чем кажется

Причина проста: эксплойт может помочь получить доступ к «холодным» вещдокам, которые годами пылились на складе. Рано или поздно Microsoft закроет уязвимость, и по мере распространения обновлений изъятые устройства уже нельзя будет расшифровать так легко, как это сделал возможным эксплойт YellowKey.

Сейчас же ситуация такова. Если у вас на складе вещественных доказательств хранятся ноутбуки, доступ к которым ранее был невозможным из-за шифрования BitLocker — сейчас имеет смысл их достать, подключить и попробовать YellowKey. Шанс на успех — высокий. Впрочем, с «холодными» вещдоками большой спешки нет: сами по себе никакие исправления на них не установятся, уязвимость останется вплоть до момента, когда вы сможете ими заняться. Просто имейте в виду: то, что ранее казалось невозможным без специфических навыков и сложного оборудования, теперь — вопрос флешки с несколькими файлами и вовремя зажатой комбинации клавиш.

TPM+PIN

В комментарии в блоге тот же исследователь заявил, что уязвимость работает и на устройствах, настроенных с TPM+PIN, и что у него есть рабочий PoC, который он намеренно не выкладывает. К этому заявлению стоит относиться с осторожностью. В теории, TPM+PIN требует ввода PIN-кода прежде, чем TPM отдаст VMK. По идее, защита надёжная, а перебор PIN-кода невозможен из-за «паники» TPM (защитный механизм от перебора PIN-кодов, работающий на аппаратном уровне). YellowKey здесь неприменим.

Но и просто отмахнуться от заявления тоже нельзя. Уже опубликованный эксплойт выявил серьёзнейшую дыру в безопасности, а там, где оставили один «чёрный ход», запросто может оказаться и другой. Так что наше мнение: держим в уме, не отмахиваемся, но и особо не рассчитываем — с учётом того, что сторонним исследователям подход исследователя к TPM+PIN воспроизвести не удалось.

Так что это было?

Вся эта история заслуживает искреннего недоумения. Что это было? Специально оставленный чёрный ход или чёрный ход, оставленный из-за безграмотности и халатности? Независимо от того, к какой точке зрения склоняетесь лично вы, очевидно одно: защита BitLocker в режиме TPM не является надёжной. Забытый год назад в такси «зашифрованный» ноутбук с чувствительными данными из рядовой неприятности внезапно превращается в угрозу, и на неё нужно реагировать. BitLocker используют корпорации и госслужащие, а защита «шифрование устройств» по-прежнему включается автоматически и работает на миллионах устройств.

Ничего подобного просто не должно было произойти. Уязвимость такой степени серьёзности, да ещё и внутри компонента, чья работа в принципе подразумевает вызов недоверенным пользователем в неаутентифицированном состоянии, должна была всплыть на внутреннем аудите задолго до релиза. То, что её не отловили, — а сверху ещё и тот факт, что реакция Microsoft на предыдущие публикации этого исследователя, по его собственному рассказу, включала тихие патчи без публичных бюллетеней, — нанесёт реальный ущерб самой презумпции «надёжности» любых средств защиты от Microsoft.

Для криминалистического сообщества это подарок, хоть и временный. Для пользователей продукции Microsoft — звоночек: время серьёзно подумать, достаточна ли используемая защита для вашей модели угроз. Для всех остальных — лишнее напоминание о том, что самые серьёзные уязвимости не обязательно хитрые и непонятные. Они могут оказаться именно такими — флешка в USB-порт и нажатая кнопка Ctrl.