YellowKeyがWinRE経由でBitLockerをバイパス、GreenPlasma CTFMON権限昇格も同時公開で未パッチ、Chaotic Eclipseはバックドアと指摘

5月Patch Tuesday翌日の2026年5月13日、4月にBlueHammerをぶつけた研究者 Chaotic Eclipse（GitHubでは Nightmare-Eclipse 名義）が、未パッチのWindowsゼロデイを2件まとめて公開した。
1件はBitLocker暗号化ドライブをUSB1本で開ける YellowKey、もう1件はCTFMON経由でSYSTEM権限を狙う GreenPlasma。
どちらもPoC（実証コード）付きで、CVEは付いていない。

YellowKeyは「これはバックドアとしか説明できない」と研究者自身が書いている。
WinRE（Windows回復環境）のイメージにだけ問題のコンポーネントが入っており、通常のWindowsインストールイメージには同名のコンポーネントが存在するのにバイパス挙動が出ない、というのがその根拠だ。

TL;DR

時系列：BlueHammerからYellowKeyまで

時期	出来事
2026-04-15	Microsoftが4月Patch TuesdayでBlueHammer（Windows Defender LPE / CVE-2026-33825）を修正、研究者がフルPoCを公開
4月中	Chaotic Eclipseが Defender 系3件 BlueHammer / RedSun / UnDefend を順次公開
5月上旬	RedSun が静かに修正される。アドバイザリなし、CVEなし。研究者は自身のブログで「サイレントパッチか」と批判
2026-05-12	Microsoft 5月Patch Tuesday
2026-05-13	YellowKey（BitLocker bypass）とGreenPlasma（CTFMON LPE）をGitHub公開
2026-06?	「big surprise」公開予告

「無告知修正」はベンダー側からするとアドバイザリ運用上の判断だが、外部の研究者にとっては「自分がレポートした穴を黙って塞いだうえで功績を消された」という構図に見える。今回の連続公開はその不満が引き金になっている、と複数メディアが報じている。

YellowKey: BitLockerバイパスの仕組み

項目	内容
種別	BitLocker フルボリューム暗号化バイパス
経路	WinRE（Windows回復環境）+ NTFS Transactions
必要なもの	USBメモリ（NTFS / FAT32 / exFAT）、物理アクセス、CTRLキー
影響	Windows 11 / Server 2022 / 2025（Windows 10は対象外）
認証	不要（BitLockerロック解除前の状態を突破する）
CVE	未割当て
パッチ	未提供

ポイントは「BitLockerそのものを暗号学的に破る攻撃ではない」ところ。
WinREの起動経路を巻き戻し、回復環境のシェル（cmd.exe）が立ち上がる状態をUSBから作り出して、そこから既にOSが知っている復号鍵でマウントされる領域を覗く、というスキームだ。

攻撃チェーン

flowchart TD
    A[攻撃者] --> B[USBメモリ準備<br/>NTFS or FAT32 or exFAT]
    B --> C["System Volume Information\FsTx\<br/>仕掛けたNTFSトランザクションログを配置"]
    C --> D[標的PCにUSB挿入<br/>BitLocker有効]
    D --> E[CTRLキー押下したまま再起動]
    E --> F[WinREが起動]
    F --> G[Windowsが添付ドライブの<br/>FsTxを走査しNTFSログをreplay]
    G --> H["X:\Windows\System32\winpeshl.ini が削除される"]
    H --> I[本来のWinREシェルではなく<br/>cmd.exe が前面に起動]
    I --> J[BitLocker保護ドライブを<br/>読み書き可能なシェルから操作]

YellowKey README（Nightmare-Eclipse/YellowKey）と複数の解析記事（Hive Security、Blackfort Technology、Bleeping Computer）を突き合わせると、肝はこの3つに集約される。

• NTFS Transactionsの再生: WindowsはNTFSのトランザクションログ（$Logfile 由来のメタデータ操作）を、起動経路で接続中のボリュームから自動でreplayする
• FsTx ディレクトリの走査: 各ボリュームの \System Volume Information\FsTx\ がトリガーになる。USB側に細工したログを置いておくと、WinREの内部ボリューム X: に対する変更として再生される
• winpeshl.ini の削除: replayの結果として X:\Windows\System32\winpeshl.ini が消えた状態でWinREが起動する。winpeshl.iniは「WinREで最初に何を起動するか」を決めるスタートアップ定義で、無い場合はフォールバックとしてcmd.exeが立ち上がる

CTRLキーは「通常起動ではなくWinREに入る」ための副ルートを叩くスイッチで、Shift+再起動からの回復ルートと組み合わせて同じ条件が作れる。物理アクセスとUSB1本が必要というだけで、ファームウェアパスワードもPINもPBA（プリブート認証）も介在しない。

なぜ「バックドア」と呼ばれているのか

研究者の主張は「同名のコンポーネントが通常のWindowsインストールイメージにも存在するが、そこでは今回のFsTx replay経路が動かない。WinREイメージにだけ動く挙動が仕込まれている」というもの。
偶然のバグであれば通常イメージ側でも同じ挙動が観測されるはず、というロジックだ。

これを真っ向から「悪意の埋め込み」と読むかどうかは別として、

• WinREは署名検証されているWindowsの一部であり、ユーザーがビルドできるOSSのリカバリ環境ではない
• そのWinREだけが、外付けボリュームのトランザクションログを自身の内部に巻き戻す挙動を持っている
• 削除されたのが「最初に何を立ち上げるか」を決める設定ファイルで、フォールバックがcmd.exe

という配置は、たまたまの取り違えで起きる絵にしてはきれいすぎる、というのが研究者の言い分だ。Microsoft側からの「これは偶然/設計上の副作用である」という説明は、現時点（2026-05-18）では公開されていない。

GreenPlasma: CTFMON経由のSYSTEM昇格

YellowKeyと同時に公開されたのが、ローカル権限昇格（LPE: 一般ユーザーからSYSTEM権限を取る攻撃）の GreenPlasma。

項目	内容
種別	ローカル権限昇格 (LPE)
対象	ctfmon.exe（Text Input Service、SYSTEMで常駐）
説明	”Windows CTFMON Arbitrary Section Creation Elevation of Privileges Vulnerability”
影響	Windows 11 / Server 2022 / 2026
PoC	未完成（フルSYSTEMシェルまでは到達しないが、メモリセクション作成までは再現可）
CVE	未割当て
パッチ	未提供

CTFMON（ctfmon.exe）は各対話ログオンセッションでSYSTEMとして走っている、IME や言語バーまわりのテキスト入力フレームワークだ。今回のPoCは、SYSTEMが書き込み権限を持つオブジェクトディレクトリ配下に、非特権ユーザーから任意のメモリセクションオブジェクトを作れるという挙動を突く。

メモリセクションは複数プロセス間で共有メモリを張るための土台で、これをSYSTEM配下のパスに差し込めると、そのパスを「自分のもの」として信用しているサービスやドライバが、攻撃者の書いた内容を踏むようになる。Bleeping ComputerやThe Hacker Newsの記事は「manipulation of privileged services or drivers that implicitly trust those paths（そのパスを暗黙に信頼しているサービスやドライバの操作）」と要約している。

研究者本人も「現状のPoCは未完成」と明記しており、すぐに既製の攻撃ツールに組み込まれる類のものではない。一方で、CTFMONはRDP・対話ログオン環境では必ず生きているプロセスのため、完成すれば横展開（横展開：侵入後に同じネットワーク内の別マシンへ進む動き）後のSYSTEM奪取に直結する。

影響範囲とリスクの見方

観点	YellowKey	GreenPlasma
攻撃前提	物理アクセス + USB	既にローカル実行できる権限
必要権限	なし（ロック画面の前から発動）	非特権ユーザー
完成度	完成（USBコピー→CTRL再起動で再現）	PoC未完成（SYSTEMシェルまで未到達）
パッチ	なし	なし
緩和策	物理アクセス禁止 / TPM+PIN / プリブート認証強化	現時点で公式緩和策なし

YellowKeyは「盗まれた / 落とした / 検査のために没収されたノートPC」を脅威モデルに置く環境にとって特に重い。BitLockerは「電源が落ちた状態の物理盗難に対するデフォルト防御」として運用されているケースが多く、PINなしのTPM-onlyや、Windows Hello PIN中心のセットアップではYellowKeyの再現条件をそのまま満たす。

逆に、以下のような構成ではYellowKeyの実害が大きく下がる。

構成	効き方
TPM + PIN（プリブート認証）	WinREに到達する前にPINが要求される
サードパーティのプリブート認証	BIOS/UEFI段階で認証を挟む
BitLocker回復キーをエスクロー＋ローテーション	一時的に開かれた事実を検知できる

物理アクセスを前提とした脅威モデルを持っていない環境では、YellowKeyの優先度は「すぐ手を動かす案件」ではなく「Microsoftの公式パッチを待つ間に、PIN必須化やWinREアクセス制限を検討する案件」になる。

GreenPlasmaのほうは、攻撃者が既にローカル実行できる前提なので、初期侵入経路（フィッシング、サプライチェーン攻撃、別のRCE）と組み合わさってはじめて意味を持つ。EDR/AVのテレメトリで \BaseNamedObjects 配下や CTFMON が触るオブジェクトディレクトリ周辺の異常な書き込みを取れるかが、検出側のポイントになる。

RedSunサイレント修正と研究者の動機

今回の同時公開には、4月から続いている RedSunサイレント修正問題 が背景にある。

• 研究者の主張: RedSun（Windows Defender系の脆弱性）を報告したが、Microsoftはアドバイザリを出さずに5月のWindows Updateで黙って修正した
• 研究者は自身のブログ（deadeclipse666）で「サイレントパッチをやるなら、こっちもアドバンス通告なしで出す」と明言
• 6月Patch Tuesday向けに「big surprise」を予告

ベンダーがCVE割当てなしで脆弱性を修正すること自体は珍しくないが、外部レポーターがいる場合に黙って閉じると、レポーター側は「自分の報告は受け取られなかったのか / クレジットを消されたのか」が判断できない。今回はそのフラストレーションが連続ゼロデイ公開という形で表面化した。

これは個別の脆弱性の技術的な話とは別レイヤーで、Coordinated Vulnerability Disclosure（CVD: 協調的脆弱性開示）の運用が壊れると外に何が出てくるか、というサンプルそのものになっている。

当面とれる行動

未パッチであることを前提に、現実的に手を動かせるのは以下あたり。

観点	具体アクション
WinREアクセス制御	自社管理PCで reagentc /disable を含む回復環境ポリシーを再点検。回復モードへの到達自体に追加認証を挟めるか確認する
BitLockerをTPM+PINに寄せる	TPM-onlyや「キーボード操作なしで起動」構成は標的そのもの。サスペンド/ロックで落ちたデバイスを守るならPIN必須化
物理セキュリティの再確認	ロッカー、移動中のかばん、修理委託先の取り扱い。「電源OFFのノートPCがUSB1本で開く」前提に切り替える
検出側	WinRE起動後の cmd.exe 表面化、X:\Windows\System32\winpeshl.ini の差分、CTFMONが触るオブジェクトディレクトリへの異常書き込みをEDRで拾えるか確認
Patch Tuesday監視	6月Patch Tuesday（2026-06-09 予定）でYellowKey / GreenPlasma / 予告された「big surprise」の扱いを確認。CVE割当てか、サイレントパッチか、上乗せ公開か

---

研究者個人の不満から連鎖的にゼロデイが落ちてくる、という流れ自体が今回いちばん不健全だと感じた。BitLockerの中身うんぬん以前に、Microsoftが受け取ったレポートをどう扱っているかの方が気になっている。