CERT/CC（米カーネギーメロン大学CERT Coordination Center）は、バックアップソフト「AOMEI Backupper」に同梱されるカーネルドライバ amwrtdrv.sys の権限昇格の脆弱性（CVE-2026-12780）を公開しました。JPCERT/CCもJVNVU#95258183として国内向けに周知しています。
問題は単なる権限昇格にとどまりません。このドライバはセキュリティ記述子のない「誰でもアクセスできるデバイスオブジェクト」として作られており、すべてのユーザーが物理ディスクへ直接書き込める状態にあります。これを使えば、ディスクの特定領域に悪意あるUEFIペイロードを書き込み、GPT（パーティションテーブル）を書き換えてEFIシステムパーティションとして参照させる——つまりOSより下の層に居座るブートキットの設置が成立します。
そして本稿執筆時点でベンダからの回答はなく、修正版も公表されていません。情シスが取れる手は緩和策のみです。
この記事でわかること
- AOMEI Backupperとは何で、なぜ社内に入り込んでいるのか
- CVE-2026-12780で何が可能になるのか（UEFIブートキットまで到達する経路）
- 修正版が無い状況で取れる3つの緩和策
- BYOVD（脆弱なドライバの持ち込み）という、もう一つのリスク
AOMEI Backupperとは何者か（無償版があることが問題を広げる）
AOMEI Backupperとは、Windows向けのバックアップ・ディスククローンソフトです。システムイメージのバックアップ、ディスク間のクローン、パーティション操作などを行います。
情シスにとっての要点は、無償版が広く出回っていることです。
- PCの入れ替えやSSD換装のときに、担当者が個人判断で入れる——これが最も多いパターンです。「古いHDDから新しいSSDにまるごとコピーしたい」というニーズに対して、検索すると上位に出てくる類のソフトです。
- 作業が終わってもアンインストールされずに残る。1回きりの用途なのに、常駐サービスとドライバが残り続けます。
- 資産管理の棚卸しで見落とされやすい。業務アプリではないため「使っていないソフト」として放置されます。
つまり組織として導入した覚えがなくても、端末単位で入り込んでいる可能性があるタイプのソフトです。ソフトウェア資産管理でインストール済みプログラム一覧を取得できる環境なら、「AOMEI」で横断検索してみてください。
何が起きるのか
CERT/CCが公開した内容によると、脆弱性の本体は不適切な権限割り当てです。
- ドライバ
amwrtdrv.sysが、セキュリティ記述子を持たないデバイスオブジェクトとして作成される - その結果、あらゆるユーザーが物理ディスクへ直接書き込める
- 攻撃者はディスクの LBA 34〜2047 の領域に悪意あるUEFIペイロードを書き込む
- GPTを書き換えて、その領域をEFIシステムパーティションとして参照させる
- 次回起動時、OSより先にそのペイロードが実行される
影響を受けるとされているのは AOMEI Backupper 8.4.0 です。
なぜ「ただの権限昇格」より深刻なのか？
OSの再インストールでは消えないからです。ブート段階に仕込まれたコードは、Windowsを入れ直しても、ディスクを初期化する範囲によっては残ります。EDRもアンチウイルスも、Windowsが起動した後の世界を見る製品なので、自分より先に動いているものは原理的に見えにくい。
ブート層の防御が破られたときの厄介さは、UEFI Shellでセキュアブート回避、4社に脆弱性やTPMのみのBitLockerは10分で解除｜研究解説でも扱いました。今回はそこに、「一般ユーザーが勝手に入れたフリーソフト経由で到達できる」という入口の広さが加わります。
ベンダ対応と、いま取れる緩和策
CERT/CCのVulnerability Note上、AOMEI Technologyのステータスは「Unknown」（ベンダ見解の提供なし）、Microsoftからもステートメントは得られていないとされています。修正版が公表されていない以上、更新で解決する話ではありません。
CERT/CCが挙げている緩和策は次の3点です。
| 緩和策 | 考え方 |
|---|---|
| amwrtdrv.sys サービスを無効化する（自動起動 → 無効） | ドライバがロードされなければ、攻撃面そのものが消えます。バックアップ機能は使えなくなる可能性があります |
| AOMEI Backupperをアンインストールする | そもそも業務で必要かを問い直すのが本筋。SSD換装のために入れたきりなら、残す理由はありません |
| UEFIでセキュアブートを有効にする | 署名されていないブートコードの実行を防ぐ防御層として機能します |
実務としては、「アンインストール」を基本方針に置き、業務上どうしても必要な端末だけドライバ無効化で凌ぐ——という順番が現実的でしょう。そしてセキュアブートは、この件とは無関係に全社で有効化しておく価値があります。
アンインストールだけでは終わらない：BYOVDという残り火
もう一つ押さえておきたいのがBYOVD（Bring Your Own Vulnerable Driver）の観点です。これは攻撃者が「正規に署名された脆弱なドライバ」を自分で持ち込んでロードさせ、カーネル権限を得る手口を指します。
今回のドライバはまさにその条件を満たします。自社の端末からAOMEI Backupperを消しても、攻撃者が外部からこのドライバファイルを持ち込めば同じことができるということです。
対策の方向としては、既知の脆弱なドライバをブロックする仕組み（Windowsの脆弱ドライバブロックリストなど）が有効かどうかを、自社のOSバージョン・エディションの前提で確認しておくのが現実的です。導入済みのEDRにドライバロードの監視機能があるなら、署名済みでも見慣れないドライバがロードされたことを検知できるかを一度確認してみてください。
現場目線の課題：「1回だけ使うつもりのソフト」が一番残る
この手の脆弱性に出会うたびに思うのですが、一番残るのは「1回だけ使うつもりで入れたソフト」です。
業務アプリなら、導入時に検討して、台帳に載って、更新の担当者が決まります。ところが「PCを入れ替えるのでディスクをコピーしたい」といったその場限りの用途で入れたツールは、誰の管理対象にもなりません。作業が終われば忘れられ、しかしドライバは自動起動のまま残ります。
しかも困ったことに、入れているのは悪意のある人ではなく、むしろ仕事を前に進めようとした真面目な担当者だったりします。「勝手に入れるな」と言うだけでは再発します。「ディスククローンが必要なときは情シスに言ってください、道具はこちらで用意します」まで示さないと止まりません。ここは啓発とセットで考えるところだと感じます。
情シスはどうすべきか
- 棚卸し：ソフトウェア資産管理の一覧で「AOMEI」を横断検索し、該当端末を特定する
- 削除／無効化：原則アンインストール。必要な端末は
amwrtdrv.sysサービスを無効化する - セキュアブート：全社で有効になっているかを確認する（この件に限らず有効）
- 再発防止：ディスククローンやバックアップの「公式に認められた手段」を情シス側で用意し、周知する
利用者向けの啓発資料としては、対策のしおり（IPA）が使いやすいです。ソフトウェアの野良導入を減らすには、禁止のルールより「困ったときの正規ルート」を示すほうが効きます。中小企業の情報セキュリティ対策ガイドライン（IPA）も、資産管理の基準づくりに使えます。
まとめ
- AOMEI Backupper 8.4.0 のドライバ amwrtdrv.sys（CVE-2026-12780）は、誰でも物理ディスクに直接書き込める状態を作る。UEFIブートキットの設置まで到達しうる。
- ベンダ回答なし・修正版なし。対応はアンインストール、ドライバ無効化、セキュアブート有効化という緩和策のみ。
- BYOVDの観点では、削除しても攻撃者が同じドライバを持ち込める。脆弱なドライバのブロックとドライバロードの監視まで含めて考える。
