Windows 11

Macrium Reflect 8が動かない、回避策は劇薬

Windows 11の4月パッチ以降、Macrium Reflect 8でバックアップイメージのマウントが失敗する。原因はMicrosoftによる署名ドライバの意図的な遮断で、出回っているレジストリ回避策はセキュリティそのものを売る劇薬だ。

情報の灯台

2026年5月3日

「正しく署名されたドライバ」が突然ロード拒否される

Macrium Reflect 8でバックアップイメージをマウントしようとすると、何の前触れもなく失敗する事象が起きている。原因は壊れたドライバでも、ライセンス切れでもない。Microsoftが正しく署名されたドライバを意図的にロード拒否するようになったからだ。

具体的には、4月14日以降に配信されたWindows 11更新プログラム「KB5083769」、および4月30日のオプションプレビュー「KB5083631」が引き金になっている。

これらのパッチをあてた環境では、Macrium Reflect 8.1の中核を担うカーネルドライバ psmounterex.sys が、Microsoftの「脆弱なドライバーのブロックリスト」に追加された結果、コード整合性ポリシーによってカーネル空間へのロードを弾かれる。バックアップ作成自体は通る場合が多いが、いざ「ファイル1つだけ取り出したい」という肝心の場面でマウントが失敗する。バックアップソフトとして致命的な機能が、静かに死んでいる状態だ。

Microsoftはこの挙動を不具合とは呼んでいない。

「これは意図された動作の変更であり、psmounterex.sysカーネルドライバの既知の脆弱性からデバイスを保護するために設計されている」

Microsoftの公式サポート記事はそう書く。バグではなく、ハードニング(強化)である、というスタンスだ。

ドライバは1次ソースに直接あたる

何が起きているかを最も詳細に整理しているのは、Malwarebytesフォーラムに投稿されたAdvancedSetup氏の技術解説だ。彼はWindows側のイベントログを引いて、こう書いている。

Microsoftはこのドライバを、コード整合性ポリシーによってカーネルロードから明示的に取り消した

Windowsの「Microsoft-Windows-CodeIntegrity/Operational」ログを開けば、イベントID 3023と3077が並んでいる。3077は「コード整合性が、認証コード署名要件を満たさないか、コード整合性ポリシーに違反するプロセスのロード試行を検出した」という記録。3023は「ドライバが、Microsoftによって取り消されたためロードがブロックされた」という記録だ。

ポリシーIDも明記されている。{D2BDA982-CCF6-4344-AC5B-0B44427B6816}。これはWindows Update経由で配信される脆弱ドライバブロックリストそのものを指している。

ドライバ自体はAdvancedSetup氏の検証によると、「PARAMOUNT SOFTWARE UK LIMITED」によって正規に署名され、有効なタイムスタンプと有効な証明書チェーンを持つ、まったく真っ当なドライバだ。問題は署名ではなく、ポリシーで許可されるかどうかに移っている。

Microsoftの言い分とユーザーの疑問

なぜブロックされたのか。Microsoftは具体的なCVE番号を公式記事で挙げていないが、背景には2023年に公開されたCVE-2023-43896がある。Macrium Reflect 8.1.7544以下のドライバに、特権昇格と任意コード実行を許す境界外書き込みの脆弱性が見つかったという、いわゆる「BYOVD(Bring Your Own Vulnerable Driver)」リスクの典型例だ。

ここで腑に落ちないのが、Macrium自身は2023年10月の時点で当該脆弱性に対する修正版(8.0.7690 / 8.1.7675)をすでにリリースしているという事実だ。修正は2年半前に出ている。

「セキュリティ更新 - CVE-2023-43896: このアップデートはpsmounterex.sysにセキュリティパッチを適用する。システムの安全のために、このリリースのインストールを推奨する」

Macriumのリリースノートにはそう書かれている。にもかかわらず、Microsoftは現時点の「最新版psmounterex.sys」も含めてブロックリストに加えた格好だ。これがいわゆる「過剰防衛」なのか、それとも未公表の追加脆弱性が背景にあるのか、Microsoftは現時点で語っていない。

Macrium UKのジョー・アレン(Joe Allen)氏もこの食い違いに気づいているらしい。フォーラム投稿でこう述べた。

「psmounterex.sysはバージョンX(10)では使われていない。だからXではイメージをマウントできる。今回の問題はバージョン8.1ユーザーで最新のWindows 11更新プログラム(KB5083769)を当てた人だけに影響する。引き続き調査し、情報が入り次第更新する」

裏を返せば、Macrium Reflect 8系を使い続けている個人ユーザーは、有料サブスクリプション制のReflect Xに移行しない限り、根本的な解決手段を持たない。

レジストリ回避策、効くがセキュリティを売る

コミュニティで急速に拡散した回避策がある。管理者権限のコマンドプロンプトで以下を実行するだけだ。

reg add "HKLM\SYSTEM\CurrentControlSet\Control\CI\Config" /v VulnerableDriverBlocklistEnable /t REG_DWORD /d 0 /f

VulnerableDriverBlocklistEnableを「0」に設定し、再起動する。これでpsmounterex.sysは再びロードされ、Macriumのマウント機能は復活する。Neowinはこの手順を取り上げ、現実的な救済策として紹介した。

しかし、ここに取り返しのつかない代償がある。

このレジストリ操作は、psmounterex.sys一つだけを許可するのではない。脆弱なドライバーのブロックリスト全体を無効にする。つまり、Microsoftが「攻撃に悪用される」と判断した数百のドライバすべてを、再びロード可能な状態に戻すということだ。

AdvancedSetup氏自身、ワークアラウンドの説明の直後に強い警告を書き加えている。

「Caveat emptor」(買い手は注意せよ)。コンピュータのセキュリティを引き下げ、攻撃面を広げている。取り消しブロックリストを無効化することは推奨しない

ラテン語の格言まで持ち出しての警告は、技術的には機能するが、本来は使うべきでない手段であることを示している。バックアップソフトを動かすために、攻撃者が長年欲しがってきた「脆弱な署名済みドライバを持ち込んでカーネルを乗っ取る」道を、自分から開け放つことになる。

「署名」が信頼の証だった時代の終わり

今回の出来事が示しているのは、Macriumの個別事情よりもむしろ、Windowsの信頼モデル全体の地殻変動だと思う。

長いあいだ、ドライバへの信頼は「正しく署名されているか」で判断されてきた。Microsoftの認証署名(WHQL)を通った、有効な証明書を持つ、適切にタイムスタンプされたドライバは、原則としてカーネルにロードを許される。これがWindows Vista以降のドライバ署名強制(Driver Signing Enforcement)が築き上げてきたルールだ。

ところがいま、署名は「会話の入り口」でしかなくなっている。ドライバが署名されていても、その署名されたバイナリに既知の脆弱性がある以上、攻撃者にとっては立派なBYOVD攻撃の素材になる。Microsoftは2022年からこの現実に対応するため脆弱なドライバーのブロックリストを段階的に拡大してきたが、Macriumのケースは消費者向けの著名なバックアップ製品が直撃された初の大規模事例といえる。

このシフトには、誰にとって良くて誰にとって悪いか、はっきりした構図がある。セキュリティ視点から見れば、これは正しい方向だ。BYOVD攻撃は実在する脅威で、ランサムウェア集団がEDRを無効化するためにわざわざ古い脆弱なドライバを「持ち込む」事例は近年急増している。Microsoftは攻撃面を一つ確実に閉じている。

一方で、ユーザーから見れば話は単純ではない。何年も使ってきた信頼できるバックアップソフトが、ある朝突然、最も使いたい瞬間に動かなくなる。「アップグレードしたReflect Xに乗り換えれば解決する」と言われても、無料版から有料サブスクリプションへの移行を強制される形になる。「セキュリティの勝利」がそのままユーザー体験の敗北になる、こういう瞬間が今回だ。

バックアップソフトはもう「便利な道具」ではない

技術的に見ると、psmounterex.sysが置かれていた位置はじつに微妙だ。バックアップイメージを仮想ドライブとしてマウントする機能は、ユーザーから見れば「エクスプローラーでファイルを開く」感覚の便利機能でしかない。だが、その下でカーネルモードのドライバが動いている。利便性の皮を被ったカーネル特権の塊、と言い換えてもいい。

この「ユーザー体感」と「技術的特権レベル」のギャップは、Windowsが長年抱え続けてきた古い問題でもある。インターフェースは「ファイルを開く」、アーキテクチャは「カーネルコードをロードする」。両者の認識ずれが、攻撃者の格好の付け入る隙になってきた。

Microsoftが今回引いた線は、「便利さのためにカーネル特権を消費させ続けることを許さない」というものだ。バックアップベンダーやストレージベンダーは、いまや単なるユーティリティ供給者ではない。カーネルサプライチェーンの一員として、自社ドライバの安全性に絶え間ない責任を負う立場に押し上げられた。

では、いま何をすべきか

実害を被っている個人ユーザーが取れる現実的な選択肢は、それほど多くない。

最も健全なのは、レジストリ回避策には手を出さず、Macrium Reflect Xへの移行か、別のバックアップソリューション(WinFsp系のユーザーモードマウントを採用した最新世代の製品)への乗り換えを検討することだろう。マウント機能を失うとはいえ、バックアップ作成は依然動作する場合が多い。リカバリ用ブートUSBを別途用意しておけば、最悪の事態であるシステム全体の復元は依然として可能だ。

組織のIT管理者にとっては、もう少し胃の痛い宿題が残る。フリート全体で、どのバックアップエージェント、ディスクツール、暗号化ユーティリティ、セキュリティ製品、ハードウェア管理スイートがカーネルドライバをインストールしているか。それぞれのバージョンは何か。Microsoftの脆弱なドライバーブロックリスト変更を、本番環境を直撃する前にテストする仕組みはあるか。これらを把握していなければ、次の更新で同じ事態が別のソフトウェアで起きたとき、同じ混乱を繰り返すことになる。

「インストールしてあとは忘れる」式のバックアップ運用が成り立つ時代は、静かに終わりつつあるのかもしれない。バックアップソフトに求められるのは、信頼できるベンダーと、絶えずアップデートされた最新バージョンと、それを検証するプロセス。災害時の最後の砦が、災害の引き金そのものになりうる。そういう時代に私たちは入っている。

参照元