セキュリティ研究者、MicrosoftがBitLockerにバックドアを作ったと主張しエクスプロイトを公開
(techspot.com)- セキュリティ研究者 Nightmare-Eclipse がYellowKeyを公開し、BitLockerのフルボリューム暗号化をパスワードなしで回避できると明らかにした
- YellowKey は、FsTxフォルダーをWindows互換ファイルシステムのUSBドライブにコピーした後、WinREで特定の手順を踏むことで再現できる
- 手順が完了すると コマンドシェル が開き、BitLockerで保護されたボリュームの参照、コピー、ファイル操作が可能になるという
- Nightmare-Eclipseは、この回避動作が 公式WinREイメージ でのみ現れるとして、意図的なバックドアの可能性を提起している
- 影響対象として Windows 11、Server 2022、Server 2025 が挙げられ、Windows 10は影響を受けないと付け加えた
YellowKeyの動作条件
- セキュリティ研究者 Nightmare-Eclipse は YellowKey を公開し、BitLockerのフルボリューム暗号化を完全に回避できると明らかにした
- YellowKeyは、添付された FsTxフォルダー をNTFS、FAT32、exFATなどのWindows互換ファイルシステムでフォーマットされたUSBドライブにコピーすることで再現できる
- USBドライブがなくても、FsTxファイルを Windows EFIパーティション にコピーし、暗号化されたディスクをシステムから一時的に切り離せば動作する可能性があるという
- その後、BitLockerで保護されたシステムを再起動して Windows Recovery Environment(WinRE) に入り、特定の入力手順に従う必要がある
- 手順が正確に完了すると コマンドシェル が表示され、パスワードなしでBitLocker保護ボリュームを参照・コピーしたり、その他のファイル操作を実行できるとされる
バックドア疑惑の根拠
- Nightmare-Eclipseは、YellowKeyは従来知られていないセキュリティバグとして見るには不自然であり、MicrosoftがBitLockerのデータ保護システムに 正規のバックドア を入れた可能性があると主張している
- 根拠は、問題を引き起こすコンポーネントが 公式WinREイメージ にしか見つからない点だという
- 同じコンポーネントは標準のWindowsインストールイメージにも存在するが、実際のシステムで観察されたBitLocker回避動作は現れないと述べている
- Nightmare-Eclipseは「これが意図的だったという事実以外に説明が思い浮かばない」と述べ、Windows 10は影響を受けず、Windows 11、Server 2022、Server 2025 のみが影響を受けると付け加えた
外部確認と追加公開
- サードパーティーの研究者らが、Nightmare-EclipseのGitHub資料に記された方法どおりにYellowKeyが動作することを 確認 したと伝えられている
- Nightmare-Eclipseは、権限昇格が可能とされる2つ目のエクスプロイト GreenPlasma も公開した
- GreenPlasmaは SYSTEMレベルのアクセス を実現する完全な概念実証コードは公開しておらず、来月のPatch Tuesday前に追加の詳細を公開する可能性を示唆している
緩和策の方向性
- YellowKeyのバックドア的な動作疑惑への緩和策は比較的単純だとされる
- セキュリティ専門家は、単一の暗号化システムだけに依存せず、十分に検証された フルディスク暗号化 の代替手段も評価するよう推奨している
- 例として VeraCrypt が挙げられている
1件のコメント
Hacker News の意見
この脆弱性を発見した研究者 Nightmare-Eclipse の投稿を見ると、ほぼ1週間前から続いていたように見える
2026年5月12日火曜日には「今回は脆弱性が2つある [YellowKey] [GreenPlasma] [...] 次のパッチチューズデーで Microsoft は大きな驚きを受けることになる」と書き、5月13日水曜日には「一連の経緯をすべて公開できるようになれば、人々は自分の激しい反応がかなり理にかなっていたと分かるだろうし、Microsoft にとってもまったく見栄えのいい話にはならない」と書いていた
投稿者のブログ: https://deadeclipse666.blogspot.com/
2026年3月の最初の投稿には「誰かが我々の合意を破り、自分は一文無しになって家も失った。彼らはこうなると分かっていながら自分を裏切った。これは自分の決断ではなく、彼らの決断だ」といった内容がある
これをどう受け止めるべきかは分からないが、内部者が事実上「リーク」しているようにも聞こえるし、他の人たちも結果を再現できているようだ
これがバックドアかどうかは、結局のところ普段から「バグかバックドアか」をどう見るかにかかっており、技術メディアが好むような「Microsoft やらかす、BitLocker がハックされる」といった単純な話ではない
核心は Windows Recovery Environment WinRE の NTFS トランザクションログ再生機能にあるバグで、外部ボリュームの NTFS トランザクションログを読み取り、それをマウントされたファイルシステムに適用できてしまう。これによって攻撃者は WinRE 認証を回避できる
PIN やパスワードのない BitLocker では、どんな認証回避でもディスク暗号化の回避になる。ブートローダーがすでにディスクをアンシールしているからであり、この構造的な「欠陥」は同じ設定の Linux にもある。たとえば Ubuntu インストーラーで比較的最近追加された Hardware Disk Encryption のチェックボックスを使う場合も同様だ
追加の証拠がない限り、NTFS トランザクションログの問題が仕込まれたバックドアなのか、単なる実装上のバグなのかは、エクスプロイト開発でよくある陰謀論をどこまで信じるか次第だ。個人的にはもっともらしいバグに見えるし、起動時アンシールの弱点はよく知られていて明白なので、これを世界を揺るがす暴露だとは思わないが、興味深いバグではある
よりよくまとまった説明: https://infosec.exchange/@wdormann/116565129854382214
公開されたエクスプロイトは PIN を使う BitLocker には影響しない。PIN がなければ BitLocker はそもそも安全ではない
元の投稿者は PIN があっても動作するエクスプロイトを持っていると主張しているが、まだその証拠は出していない
BitLocker に PIN を必須にしている会社は見たことがない
出典: https://infosec.exchange/@wdormann/116565129854382214
「一般的な WinRE セッションには X:\Windows\System32 ディレクトリがあり、その中に winpeshl.ini ファイルがある」
「しかし YellowKey エクスプロイトでは、USB ドライブ上の Transactional NTFS の断片によって、別のドライブの winpeshl.ini ファイルを削除できるように見える」
興味深い。この環境にはあまり詳しくないが、単純にファイルハンドルを作成または受け渡してしまう問題なのだろうか？ だとしたら、なぜ WinRE の再起動中にキー入力が必要なのだろう？
パッチ適用がどの程度可能なのかも気になる。無数の WinRE USB ドライブには手を入れられないはずなので、BitLocker 側でアクセス権を更新できるのだろうか？ 復号/再暗号化が必要になるのだろうか？ 今後さらに多くの情報が出てきそうだ
そのため、この攻撃では Ubuntu ライブ CD のようなものではなく WinRE が必要になる
また、既存の WinRE USB ドライブをすべてパッチする必要はない。Secure Boot の署名を失効させれば TPM 検証を通れなくなり、その結果どのディスクも復号できなくなる
「セキュリティ専門家は一般に、単一の暗号化システムに依存せず、VeraCrypt のような十分に検証された フルディスク暗号化 の代替手段を評価するよう勧めている」
もし FDE にバックドアを入れたのなら、人々に Windows 自体の利用をやめて Linux を使えと言うほうがもっと筋が通る
FDE にバックドアを入れたのなら、OS 自体にもバックドアが1つしかないとは考えないだろう。プロプライエタリソフトウェアはまったく信用すべきではないし、きちんと監査されていないオープンソースも信用すべきではない
これは BitLocker 専用の問題というより、ログイン回避 に近く見える。PIN なしで TPM に依存すると自動的に復号される
通常は攻撃者がログイン画面を突破できないので問題ないはずだが、このエクスプロイトは回復環境で制限のないシェルを得る方法を示しているようだ
研究者は PIN も回避する方法があると主張しているが、まだ公開していない
セキュリティ専門家が「Microsoft 製品のセキュリティ」という役割を断り始めるのはいつになるのだろう？ 自分はもうその段階に来ている
Microsoft 製品のセキュリティは、MS の狂った技術的負債と強欲の次の波でまた崩壊するまで続く忙しい仕事にすぎない。今やバックドアまである
すべてのコンプライアンス規則を満たし、MS の影響を受けた「ベストプラクティス」に従っているので、何が起きても自分の責任ではないと言えるようになる
E2E 暗号化バックアップのために ADP を有効化することはできるが、会話相手が有効化していない可能性が高いため、大して役に立たないかもしれない
Microsoft を擁護したいわけではなく、こうした企業はどこも PRISM の一部だったという話だ
昔、ある Windows NT のバージョンが誤ってデバッグシンボルを有効にしたまま出荷されたとき、Microsoft が「予備キー」だと主張していたキー名がなぜ ..._NSAKEY だったのかについて話そうか
たった一度、本当にたった一度だけ Windows がデバッグシンボルを有効にしたまま出荷されたのに、よりによって暗号鍵の名前が「NSAKEY」だった
もちろん、国家の不正にずっと目をつぶってきた人たちは、それが完全に普通のことだと言い、当時 Microsoft が苦心して作った「バックドアではない」という言い訳をそのまま繰り返すだろう
エクスプロイトをもう少し掘ってみると、これは TPM 専用モードの BitLocker を狙っている。つまり事前ブート認証のようなものはない
Secure Boot がブートチェーンを検証すると、TPM が自動的に暗号鍵を渡す。物理アクセスがあれば大きな違いはない
エクスプロイト入りの USB で起動して緊急シェルを得るにせよ、5ドルのマイクロコントローラーを買ってマザーボードの特定ピンに半田付けし、TPM キーをスニッフィングするにせよ可能だ
Microsoft は全体として安全でないものを売りながら、それをフルディスク暗号化として売っている。USB メモリにエクスプロイトを入れてシェルを取り、ファイルを漁ってコピーできるような人なら、マイクロコントローラーを買って YouTube の半田付け動画を見ながら真似することもできる
だから問題は「エクスプロイト」そのものではなく、Microsoft が売っている 偽りの安心感 だ
5ドルのマイクロコントローラーで特定ピンに半田付けして TPM キーをスニッフィングできるのは dTPM の場合だけだ。fTPM はこれに脆弱ではなく、dTPM よりはるかに広く使われている
起動時にパスフレーズを入力するのはすでに筋肉の記憶になっていて、信頼できるシンプルなセキュリティを与えてくれる
マザーボードがなくてもデータを復旧できる
日常用途では、evil maid 攻撃を防ぐために Secure Boot+TPM+パスフレーズを組み合わせたスロットを使い、バックアップ用のパスフレーズスロットをもう1つ持つようなハイブリッドなら悪くないかもしれない
https://deadeclipse666.blogspot.com/2026/05/were-doing-silen...
これは BitLocker への攻撃というより Secure Boot チェーン への攻撃に見える
PIN なしのアンロックに価値があるのは、脅威モデルがディスク廃棄、ディスク取り外し、TPM とディスクの分離程度に限定される場合だ
デバイスを複数人が定期的に使うなら、PIN 入力は不便または不可能なことがある。そのため、アクセス検証制御を信頼された OS コンポーネントに委ねる構成になる
「TrueCrypt の使用は安全ではなく、未修正のセキュリティ問題が含まれている可能性がある」という文言を覚えている人はいる？ ;)