Windows 11 23H2 (OS Build 22631.4890) に 2025 年 2 月の累積更新プログラム KB5051989 を適用すると、AppLocker のパス規則が想定外の挙動を示し、マルチアプリ キオスク端末で本来ブロックすべき実行ファイルが起動できてしまう事例が報告されています。本記事では発生メカニズムの詳細解析、影響評価、緊急回避策、恒久対策、運用監視のポイントまで網羅的に解説します。
概要と影響範囲
KB5051989 適用後、既存の AppLocker パス規則C:\Program Files\Microsoft\Edge\msedge.exe
のみを許可している環境でも、次の手順でコマンドプロンプトなど任意の実行ファイルが起動できるようになります。
cmd.exeをユーザー書き込み可能なフォルダー (例:%LOCALAPPDATA%) へコピー- ファイル名を
msedge.exeに変更 - 当該ファイルを実行
更新前は同操作で 0x800704ec (AppLocker によりブロック) が表示されていたため、KB5051989 による回帰バグと考えられます。マルチユーザー端末・共用端末・教育機関の PC 教室など、キオスク モードを採用している環境で深刻なセキュリティ リスクが生じます。
再現試験の詳細
検証環境
- Windows 11 Pro 23H2 (22631.4890)
- ローカル GPO で AppLocker 有効化 (実行ファイル規則のみ)
- キオスク構成ツールでマルチアプリ キオスクを構成し、許可アプリを Microsoft Edge のみに設定
現象観測
PS C:\Users\Kiosk> copy C:\Windows\System32\cmd.exe msedge.exe
1 個のファイルをコピーしました。
PS C:\Users\Kiosk> .\msedge.exe
C:\Users\Kiosk\msedge.exe> _ ← コマンドプロンプトが起動
同一手順を KB5051989 未適用の 22631.4377 で実施すると、イベント ID 8004 (実行がブロック) が記録され起動できませんでした。
原因の考察
AppLocker のパス規則は「フルパス一致」ではなく「実行時に解決されるカーネル オブジェクト名」に基づいています。KB5051989 では LogonUI との連携モジュールが更新され、キオスク セッションの DEVICE\HARDDISKVOLUME 名前空間解決ロジックが変更された可能性が高いとみられます。結果として、NTFS 名前付きストリームに付随する「実体ファイルのオリジナルパス」が検証に含まれず、単純なファイル名比較にフォールバックしていると推測されます。
同バイパスは名称偽装のみで成立し、署名検証を行わない点が根本原因です。
セキュリティ リスク評価
| リスク | 影響 | 悪用難易度 |
|---|---|---|
| 特権昇格 (EoP) | キオスク利用者が管理者権限プロンプトを開きローカル昇格 | 中 |
| 縦方向移動 | 同一 VLAN 内の端末へ PowerShell Remoting で侵入 | 中 |
| 機密情報漏えい | 資格情報キャッシュやブラウザー Cookie の抽出 | 低〜中 |
特に教育機関・公共施設など物理的に端末へアクセスできる第三者が存在する環境では、システム全体のセキュリティバウンダリが崩壊しかねません。
暫定的な回避策
| 区分 | 対応内容 |
|---|---|
| 更新ロールバック | KB5051989 をアンインストール (DISM /Online /Remove-Package /PackageName:PackageforRollupFix~31bf3856ad364e35~amd64~~22631.4890.1.9)wusa /uninstall /kb:5051989 /quiet /norestart でも可 |
| 更新延期 | Intune or WSUS で「一時停止」リングを設定メンテナンススケジュールをずらし段階的展開 |
| 別イメージ利用 | Autopilot 用ベースイメージから KB5051989 を除外してゴールドイメージを再構築 |
構成変更による恒久対策
1. ハッシュ規則の併用
名称偽装だけではバイパスできないSHA‑256 ハッシュ規則に置き換えます。ただしアプリ更新のたびにハッシュ計算が必要なため、スクリプト自動化 (例: CI/CD パイプラインで Get-AppLockerFileInformation を実行し XML を差し替え) を推奨します。
2. 発行元 (Publisher) 規則
Edge 等の Microsoft 署名バイナリのみを許可する方法です。署名検証が走るためリネーム耐性があります。
3. Windows Defender Application Control (WDAC) への移行
WDAC は Kernel モードでコーサイン済みカタログを確認し、名称変更・シンボリックリンクでのバイパスが不可能です。特にキオスク端末のようなロックダウン用途では WDAC + HVCI (Hypervisor Enforced Code Integrity) を有効化することで攻撃面を大幅に縮小できます。
基本ポリシーを作成
New-CIPolicy -Level Publisher -FilePath .\WDAC_Policy.xml -UserPEs 0
サービスモード用に変換
ConvertFrom-CIPolicy -XmlFilePath .\WDACPolicy.xml -BinaryFilePath .\WDACPolicy.bin
適用
Copy-Item .\WDAC_Policy.bin "C:\Windows\System32\CodeIntegrity\SiPolicy.p7b"
監視と検知を強化する
AppLocker Operational Log
- パス:
Applications and Services Logs\Microsoft\Windows\AppLocker\MSI and Script - イベント ID 8003 (許可) 8004 (ブロック) を収集
- SIEM へ転送してリアルタイムアラート
WDAC Audit モード
移行段階で Option 3 (Audit Only) を付与し、イベント ID 3076 を確認します。
Microsoft へのフィードバック手順
- Microsoft Learn Q&A で「Windows 11 Servicing」タグを付け投稿
- 事象再現動画 (MP4) と
gpresult /hレポートを添付 - Feedback Hub のカテゴリ「Security & Privacy > AppLocker」からも送信 (再現手順を英語併記)
- サポート案件 (Premier/PSS) を保有している場合は SR をオープンし、
%windir%\Logs\CBS\CBS.logとEventViewer.evtxを事前アップロード
複数経路で報告を重ねることで修正優先度が上がる傾向があります。
FAQ: よくある質問
Q. 累積更新はロールアップ形式だが個別 KB を除外できるか? A. WU では不可。WSUS か Configuration Manager で「更新の置換関係」を利用し Skip するか、DISM で手動除外します。 Q. WDAC はサードパーティ製ブラウザーも許可できる? A. New-CIPolicy -Level Hash で Chrome 等の署名をカタログ化すれば可能。ただし自動更新との整合に注意。 Q. 影響を最小限に検証する方法は? A. Microsoft Test Base for Microsoft 365 に仮想マシンを登録し、Update Staging Lab で事前適用→自動テストを推奨。
まとめと今後のロードマップ
KB5051989 適用後の AppLocker バイパスは、パス規則の本質的な脆弱性を露呈した形でもあります。キオスク端末を含むロックダウンシナリオでは、
- 短期: KB5051989 のロールバック、更新延期
- 中期: ハッシュ規則・発行元規則にリファクタリング
- 長期: WDAC + HVCI へ全面移行
というステップで多層防御を固めることが現実的です。特に教育・公共空間では恒久対策が完了するまで物理監視を強化し、USB ポート無効化・BIOS パスワード設定も並行して実施してください。Microsoft から修正パッチが公開された際には、パイロット端末で再現テストを行い、イベントログに不審な許可イベントが一切記録されないことを確認してから本番展開することを強く推奨します。
本記事がキオスク端末を運用する皆様の迅速なリスク低減と今後のセキュリティ設計の一助となれば幸いです。
コメント