SignDrop：Windows CLFS の SYSTEM 権限昇格
公開された Windows CLFS の実証コードが、修正済みの Windows 11 と Server 2025 でログ認証を SYSTEM 権限に変えます。修正はありません。
要点
- SignDrop と呼ばれる公開実証コードが、Windows の Common Log File System 認証機能を悪用し、修正済みの Windows 11 と Server 2025 で標準ユーザーを SYSTEM に変えます。研究者 MSNightmare が 2026 年 11 月 10 日に公開しました。
- 影響を受けるのは、CLFS 認証モードが 0 または 1 の Windows 11 25H2、26H1、26H2 と Windows Server 2025 です。公開チェーンは Windows Defender が有効であることも必要とします。
- CVE、Microsoft のアドバイザリ、修正はありません。独立したテストはエクスプロイトが動作することを確認しましたが、運用に使えるほど信頼できるものではありません。攻撃の報告はなく、2026 年 11 月 13 日時点で CISA KEV に登録されていません。
- 回避のために CLFS 認証を無効にしないでください。モード 2 または 3 は、この緩和策が防ぐメモリ破壊の不具合を再び開きます。緩和策を有効に保ち、ローカルの標準ユーザーアクセスを制限し、Microsoft がアドバイザリを公開するか注視してください。「修正方法」を参照してください。
影響を受けますか？
次の条件がすべて当てはまる場合に影響を受けます。
- デバイスが Windows 11 25H2、26H1、26H2、または Windows Server 2025 を実行している。研究者は Windows 11 26H2、26H2 Experimental ビルド、Windows Server 2025 Experimental ビルドでテストしました。
- CLFS 認証モードが 0（適用）または 1（学習）である。Microsoft は緩和策を既定で有効にし、90 日後に学習から適用へ移行するため、両方のモードが対象です。
- Windows Defender が有効である。公開チェーンは Defender の更新エンジンに、攻撃者が用意したログを開かせます。
- ローカルの標準ユーザーがデバイスでコードを実行できる。この不具合はローカル権限昇格であり、リモート攻撃ではありません。
古い Windows リリースには CLFS 認証機能がないため、SignDrop の経路は適用されません。ただし CLFS ドライバーはログファイルを解析し続け、緩和策が防ぐはずだったメモリ破壊の不具合は別のリスクとして残ります。
| 製品 | 影響を受けるバージョン | 修正バージョン |
|---|---|---|
| Windows 11 | 25H2、26H1、26H2 | なし |
| Windows Server | 2025 | なし |
| 古い Windows リリース | CLFS 認証機能なし | SignDrop は適用外。CLFS のメモリ破壊不具合は残る |
デバイスの CLFS 認証モードを読み取ります。
reg query "HKLM\SYSTEM\CurrentControlSet\Services\CLFS\Authentication" /v Mode
PowerShell でも同じ値を読み取れます。
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\CLFS\Authentication' -Name Mode
Mode が 0 または 1 なら研究者の主張する範囲です。Mode が 2 なら管理者が緩和策を無効にし、3 ならシステムが無効にしています。どちらもデバイスを安全にはしません。どちらも CLFS に改ざんされたログを解析させ、緩和策が減らすはずだったメモリ破壊の露出を戻します。
Windows のビルドは winver または次のコマンドで確認します。
Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber
修正方法
修正はありません。Microsoft は CVE を割り当てず、アドバイザリも公開せず、パッチも提供していません。2026 年 11 月のセキュリティ更新も SignDrop に対処していません。
- CLFS 認証を有効に保ちます。
Modeは 0 または 1 のままにします。この不具合を避けるために 2 または 3 にしないでください。CLFS のメモリ破壊経路が再び開きます。 - ローカルログオンと標準ユーザーアカウントを必要な人だけに制限します。公開チェーンは標準ユーザーセッションから始まります。
- CVE、アドバイザリ、変更された緩和策について Microsoft の Security Update Guide と CLFS 認証のサポート記事を監視します。
- 標準ユーザーがコードを実行できるデバイスで「侵害されたかどうかを確認するには？」のチェックを実行します。
緩和策を有効に保ったまま公開チェーンを阻止する証明済みの回避策はありません。Windows Defender の改ざん防止は公開経路では役立ちません。チェーンは Defender 自身の特権プロセスにファイル作成を依頼するためです。信頼できないユーザーをリモートセッションや別デバイスに移すなどしてローカルコード実行をなくせば前提は消えますが、常に現実的とは限りません。
Microsoft のサポート記事は緩和策とレジストリ値を説明しています。また、緩和策を無効にすると CLFS が認証されていないログを解析できるようになるため、設定を有効に保つ必要があると警告しています。
根本原因は何ですか？
CLFS ドライバーは、ログを開いたプロセスのコンテキストで認証ファイルを作成しますが、新しいファイルに元のログの権限を与えます。そのため、特権プロセスに SYSTEM 所有のファイルを作成させ、標準ユーザーがそれに書き込めるようにできます。
CLFS は Common Log File System と呼ばれる Windows のカーネルモードログサブシステムです。Microsoft は 2025 年 10 月に認証緩和策を追加しました。ドライバーは、レジストリに保存され管理者と SYSTEM だけが読めるキーを使って、ハッシュベースのメッセージ認証コードをログファイルに付けます。
各ログには関連コンテナと、復旧データを持つ .cnpf コンパニオンファイルを置けます。コンパニオンファイルは、Microsoft の文書によれば元のログと同じセキュリティ属性で作成されます。
公開分析は、関連コンテナを持つログを開いたときの動作を説明しています。ドライバーは関連コンテナも開きます。関連ファイルが空で認証ファイルがない場合、CLFS は .cnpf ファイルを作成します。
作成はログを開いたプロセスのコンテキストで実行されるため、特権プロセスはファイルを SYSTEM として作成します。新しいファイルは元のログの随意アクセス制御リストを継承し、それを標準ユーザーが制御します。
2 つ目はリダイレクトです。オブジェクトマネージャーのシンボリックリンクで .cnpf のパスを攻撃者の選んだ場所に向けられます。特権プロセスがログを開くと、CLFS はリンクをたどり、攻撃者のパスにファイルを SYSTEM として、元のログの権限のまま作成します。
研究者の例は \CLFS\??\C:\test\t を開き、t.blf とその関連コンテナを開きます。
Microsoft の文書はモード値を次のように定義しています。
- 0：緩和策が適用される。CLFS は認証コードがない、または無効なログを拒否します。
- 1：学習モード。CLFS はログを開き、認証コードがない場合に書き込みます。
- 2：管理者が緩和策を無効にした。
- 3：システムが緩和策を無効にした。
モード 0 と 1 が脆弱な構成です。どちらでも認証ファイルが作成されるためです。
どのように悪用されますか？
- 標準ユーザーが、自分で制御するパスで CLFS ログと関連コンテナを作成し、関連コンテナを空にして認証ファイルを欠落させます。
- ユーザーが、
.cnpfの作成を自分が到達できるパスへリダイレクトするオブジェクトマネージャーのシンボリックリンクを作成します。 - ユーザーが特権プロセスにログを開かせます。公開実証コードは Windows Defender の更新インターフェース
ServerMpUpdateEngineSignatureを呼びます。 - CLFS は特権プロセスのセキュリティコンテキストで
.cnpfファイルを作成するため、ファイルは SYSTEM 所有になります。新しいファイルは元のログの随意アクセス制御リストを継承し、ユーザーはそれに書き込めます。 - ユーザーが SYSTEM 所有のファイルに書き込み、その書き込みを SYSTEM シェルにつなげます。
公開リポジトリには実証コードと分析があります。研究者は Windows 11 26H2、Windows 11 26H2 Experimental ビルド、Windows Server 2025 Experimental ビルドでテストしました。リポジトリは、特権プロセスで動くあらゆるマルウェア対策エンジンに技術を使えると述べていますが、その広い主張は独立にテストされていません。
The Hacker News が報じた 78researchlab の独立評価は、エクスプロイトは動作するが運用に使えるほど信頼できないと結論しました。実行するとすべてのユーザーアカウント制御のプロンプトが標準ユーザーシェルと SYSTEM シェルを開くようになり、デバイスの前にいる人に攻撃が目立ちます。
攻撃の流れは？
標準ユーザーが CLFS ログとリダイレクトされたコンパニオンパスを用意し、Defender にログを開かせて、CLFS がユーザーに書き込める SYSTEM 所有のファイルを作成します。
コンテナを作成"] --> B["オブジェクトマネージャーのリンクが
.cnpf パスをリダイレクト"] B --> C["Defender の更新インターフェースが
用意されたログを開く"] C --> D["CLFS が .cnpf を
SYSTEM として作成"] D --> E["ファイルはユーザーが制御する
ログの権限を継承"] E --> F["標準ユーザーが SYSTEM 所有
ファイルに書き込む"] F --> G["書き込みが SYSTEM シェルに
つながる"]
攻撃者に何ができますか？
ローカルの標準ユーザーが、影響を受けるデバイスで SYSTEM 権限を得られます。これは Windows のワークステーションやサーバーで最高のローカル権限であり、攻撃者は他のユーザーのデータを読み、システム構成を変更し、ドライバーを読み込み、セキュリティソフトを無効にできます。
条件は影響の一部です。
- 攻撃者には標準ユーザーセッションと、デバイスでコードを実行する能力が必要です。
- CLFS 認証モードが 0 または 1 である必要があります。
- 公開チェーンには Windows Defender が有効である必要があります。チェーンは Defender の更新インターフェースを使ってログを開くためです。
- 公開チェーンはローカル権限昇格です。それ自体でリモートアクセスを与えず、他のデバイスに広がりません。
研究者は、特権プロセスを実行するあらゆるマルウェア対策エンジンに技術を使えると述べています。その主張は、特定の Windows ビルドで Defender を使った公開テストより広いものです。独立テストはテスト済みビルドで SYSTEM シェルを確認したもので、すべての構成で信頼できる悪用を確認したものではありません。
修正が機能する理由
修正は存在しないため、この節では修正が変えるべき点を説明します。完全な修正は、特権プロセスが自分で制御しない権限のファイルを作成できないようにする必要があります。
3 つの変更が公開経路を閉じます。
- 認証ファイルを元のログ所有者のセキュリティコンテキストで作成する、または作成前に開いたプロセスの身元を再確認する。
- 特権コンテキストでファイルを作成するとき、ログ作成者が制御する随意アクセス制御リストを継承しない。
- 関連コンテナのパスをログのディレクトリに対して検証し、特権作成でのオブジェクトマネージャーリダイレクトを拒否する。
Microsoft はパッチも CVE も公開していません。公開されるまで、緩和策を有効に保つことが、機能が導入された保護を維持する制御です。無効にすると、ローカル権限昇格を、緩和策が防ぐはずだったメモリ破壊の不具合と引き換えにします。
侵害されたかどうかを確認するには？
侵害の指標は公開されておらず、攻撃の報告もありません。公開エクスプロイトは目立つため、これらのチェックはそれが作る状態を探します。
- 予期しない場所、特にユーザーが書き込めるディレクトリで、SYSTEM 所有の
.cnpfファイルを探します。コンパニオンファイルは通常、ログの隣にあります。 - CLFS のパスからユーザーが書き込める場所へ向かうオブジェクトマネージャーのシンボリックリンクを探します。WinObj などのビューアで
\CLFS名前空間を確認できます。 - ユーザーアカウント制御の動作変化を確認します。公開エクスプロイトは UAC プロンプトを標準ユーザーシェルと SYSTEM シェルに変えます。
- 予期しないログファイルのオープン前後の Defender とシステムのイベントを確認し、標準ユーザーセッション後に作成された新しいローカルアカウントやサービスを探します。
- メンテナンス時間外に読み込まれた予期しない SYSTEM プロセスやドライバーを確認します。
失敗した試行は痕跡を残さないことがあります。チェックにヒットした場合は、ディスクイメージを保存し、その場で清掃するのではなくデバイスを再構築してください。
年表
- 2025-10-28: Microsoft が Windows 11 25H2、26H1、Windows Server 2025 の更新で CLFS 認証緩和策を提供（KB 5056852）。
- 2026-11-10: MSNightmare が GitHub で SignDrop の実証コードと分析を公開。
- 2026-11-12: The Hacker News が不具合と 78researchlab の独立テストを報道。エクスプロイトは動作するが信頼できないと結論。
- 2026-11-13: CVE、Microsoft のアドバイザリ、修正はなし。CISA KEV にも未登録。
よくある質問
SignDrop の CVE はありますか？
いいえ。Microsoft は 2026 年 11 月 13 日時点で CVE を割り当てず、アドバイザリも公開せず、修正も提供していません。研究者はゼロデイと呼び、公開リポジトリが唯一の技術記録です。
Windows 10 は影響を受けますか？
CLFS 認証機能は Windows 11 25H2、26H1、26H2、Windows Server 2025 にあります。古いリリースにはないため、SignDrop の経路は適用されません。ただし CLFS ドライバーにはメモリ破壊の不具合が残り、別のリスクです。
リモートから悪用できますか？
いいえ。公開チェーンはデバイス上の標準ユーザーセッションから始まり、ローカルコード実行を必要とします。ローカル権限昇格であり、リモートコード実行の不具合ではありません。
防ぐために CLFS 認証を無効にすべきですか？
いいえ。モードを 2 または 3 にすると緩和策が無効になり、CLFS が改ざんされたログを解析できるようになり、機能が防ぐはずだったメモリ破壊の不具合が再び開きます。モードは 0 または 1 に保ってください。
Defender の改ざん防止はエクスプロイトを止めますか？
公開チェーンでは止めません。チェーンは Defender 自身の更新インターフェースにログを開かせ、ファイル作成を Defender の信頼されたプロセス内で行います。研究者はこれが自己防御を回避できる理由だと述べ、独立テストはテスト済みビルドで SYSTEM シェルを確認しました。
実環境で悪用されていますか？
2026 年 11 月 13 日時点で攻撃の報告はありません。エクスプロイトは公開されていますが、独立テストは信頼性が低く目立つと判断し、CISA KEV にも登録されていません。
参考資料
- MSNightmare、SignDrop の実証コードと技術分析、2026-11-10 公開: https://github.com/MSNightmare/SignDrop (2026 年 11 月 13 日確認)
- Microsoft、「Common Log File System (CLFS) Authentication Mitigation」、KB 5056852、初回公開 2025-10-28、モード値とコンパニオンファイルのセキュリティ属性: https://support.microsoft.com/en-us/servicing/os/windows/2025/03/common-log-file-system-clfs-authentication-mitigation (2026 年 11 月 13 日確認)
- The Hacker News、「New SignDrop Zero-Day Exploit Turns Windows CLFS Security Feature Into SYSTEM Access」、2026-11-12、エクスプロイトチェーン、独立テスト、影響ビルド: https://thehackernews.com/2026/11/new-signdrop-zero-day-exploit-turns.html (2026 年 11 月 13 日確認)
- CISA の悪用済み脆弱性カタログ JSON フィード、2026 年 11 月 13 日に SignDrop を確認（未登録）: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (2026 年 11 月 13 日確認)
- Microsoft Security Update Guide、2026 年 11 月 13 日に SignDrop の CVE またはアドバイザリを確認（なし）: https://msrc.microsoft.com/update-guide (2026 年 11 月 13 日確認)