https://error-daizenn.hatenablog.com/entry/2025/09/25/145348

2025年9月24日、セキュリティ研究チーム「Zero Salarium」が発表した新たな手口が、サイバーセキュリティ業界で大きな注目を集めています。
Windows 11 24H2の完全パッチ適用環境でも、古い「WerFaultSecure.exe」を悪用することでLSASSからキャッシュされたパスワードを盗み出せる というのです。

この脆弱性は、Windowsの後方互換性が逆に悪用された典型例であり、今後の攻撃シナリオに直結する危険性を示しています。

LSASSとPPLの基本 ― なぜ狙われるのか？

攻撃の標的となる LSASS（Local Security Authority Subsystem Service） は、Windowsにおいて認証情報を管理する重要なプロセスです。
平文パスワードやNTLMハッシュが一時的にキャッシュされるため、攻撃者にとっては「金庫の中の鍵」に等しい存在です。

Windows 11では、LSASSへの直接アクセスを防ぐため PPL（Protected Process Light） が導入されています。
これにより、カーネル権限や同等のPPL権限を持つプロセス以外はLSASSにアクセスできない設計になっています。

しかし今回の研究は、「古いWerFaultSecure.exe」をPPLプロセスとして動かすことで、この防御を迂回できる ことを証明しました。

悪用される「WerFaultSecure.exe」とは？

WerFaultSecure.exeはWindowsの WER（Windows Error Reporting） に属する正規ツールで、
クラッシュ時に保護されたプロセスからダンプを取得する役割を持っています。

通常は暗号化されたダンプが生成されるため安全ですが、Windows 8.1版のWerFaultSecure.exeには「暗号化されないままダンプを書き出す欠陥」 が存在していました。

研究者はこの古いバイナリをWindows 11上にコピーし、PPL権限で実行させることで 暗号化されない生のLSASSダンプ を取得することに成功しました。

実際の攻撃手順（Zero Salariumの報告より）

Zero Salariumの解析によれば、攻撃者は次のような流れで悪用可能です。

(1) 古いWerFaultSecure.exeを用意
Windows 8.1から抽出した脆弱なバージョンをターゲット環境に配置。

(2) PPL昇格を利用して起動
CreateProcessAsPPL APIを使い、PPL保護プロセスとしてWerFaultSecure.exeを実行。

(3) 隠しオプションでLSASSを指定

/h : セキュア隠しクラッシュモード
/pid [pid] : LSASSのプロセスID指定
/tid [tid] : メインスレッドを指定
/file [handle] : 出力ファイルを指定

(4) WSASSローダーで制御
カスタムローダー「WSASS」がWerFaultSecure.exeを操作し、ダンプ生成後にファイルヘッダーを書き換え。

(5) アンチウイルス回避
生成されたダンプファイルの先頭4バイトをPNG形式に偽装し、検知を回避。
後にMDMP（ミニダンプ）ヘッダーに戻すことで、通常の解析ツールで利用可能に。

(6) 認証情報を抽出
完成したミニダンプをMimikatzやpypykatzに読み込ませ、NTLMハッシュや平文パスワードを取り出す。

攻撃成功後の被害シナリオ

この攻撃が成功すると、被害者の環境から以下の情報が奪われる可能性があります。

ドメインユーザーの認証トークン
ローカル管理者アカウントのパスワード
保存されているNTLMハッシュ
企業ネットワーク内での横展開（ラテラルムーブメント）の足掛かり

つまり、単なる1台の侵害にとどまらず、企業全体のネットワークが一気に掌握されるリスク があるのです。

防御策と検出のポイント

現時点でMicrosoftから公式パッチは出ていませんが、防御側にできることはあります。

WerFaultSecure.exeの存在を監視：特にSystem32以外の場所にある場合は要注意
PPLプロセスの起動イベントを監視：不審なパラメータ付きで実行されていないか確認
EDRによる異常ファイル作成の検知：PNGとして偽装されたMDMPファイルの生成をトリガーにする
最小権限の原則を徹底：侵入後にWerFaultSecure.exeを仕込まれないよう、管理者権限の利用を制限

また、企業環境では アプリケーション制御（AppLockerやWDAC） を導入し、正規バイナリ以外の実行を禁止することも有効です。

セキュリティコミュニティでの議論と反応

Zero Salariumが今回の手口を公開して以来、世界中のセキュリティ研究者やインシデント対応チームの間で議論が巻き起こっています。

Redditのセキュリティフォーラムでは、研究者たちが「Windowsの後方互換性が最大の弱点になっている」と警鐘を鳴らしています。
あるユーザーは「WerFaultSecure.exeのような古いバイナリを禁止しない限り、この問題は繰り返される」と投稿しました。

X（旧Twitter）上でも、セキュリティアナリストやペネトレーションテスターが「PoC（Proof of Concept）」の存在に触れながら、
「攻撃者がエクスプロイトを現実世界で使い始めるのは時間の問題だ」 と警告を発しています。

企業のSOC（Security Operations Center）担当者にとっても、これは単なる研究報告ではありません。
すでに「脅威アクターがこの手法を利用している兆候がある」との初期報告も一部で共有されており、
近い将来に実際の攻撃キャンペーンで悪用される可能性が極めて高い と見られています。

過去のLSASS狙い攻撃との比較

LSASSからの認証情報抽出は、サイバー攻撃の常套手段です。
過去には「Mimikatz」を使った直接的なダンプ取得が広く行われてきましたが、
Windowsのセキュリティ強化により難易度は上がっていました。

特に、PPL（Protected Process Light）の導入によって、
「カーネル権限がなければLSASSにアクセスできない」という強固な制約が設けられました。

しかし今回の手口は、Windows自身の正規ツールを“トロイの木馬”として利用する点 が従来の攻撃とは異なります。
これは「Living off the Land」（既存の正規機能を攻撃に転用する手法）の進化形といえます。

MimikatzやDumpertといったツールを使う場合、セキュリティ製品に検知されやすいですが、
WerFaultSecure.exeのようなMicrosoft署名付きバイナリを使えば、EDRやアンチウイルスの監視をすり抜けやすい のです。

防御側が直面する課題

今回の問題は、防御側にいくつもの課題を突きつけています。

署名付きバイナリの信頼性低下
セキュリティ製品は長年、署名付きバイナリを「信頼できる」とみなしてきました。
しかし古い正規ファイルが悪用されるなら、その前提は成り立たなくなります。
後方互換性のジレンマ
Microsoftは企業ユーザーのために古い機能との互換性を維持してきました。
その方針がセキュリティ上の弱点を生んでいる現状は、根本的な再考を迫られています。
監視対象の増加
防御側は「System32以外に置かれたWerFaultSecure.exe」を監視する必要がありますが、
実際には無数の正規ファイルが存在するため、監視範囲が膨大になります。