Security

数分だけの改ざんをどう調べる？AOMEIの更新配信基盤を狙った攻撃

公開日2026.10.17

更新日2026.10.18

約8分で読めます

※本ページのリンクにはプロモーションが含まれています。

短時間だけ変更された更新設定と配布パッケージを時計の断片で表すフラットな概念イラスト

この記事のポイント

対象: AOMEI Backupper
情報の種類: 二次情報のみ
公表日: 2026.10.15

Google Threat Intelligence Group（GTIG）とMandiantは2026年10月15日、AOMEI Technologyの更新配信基盤を狙った攻撃の調査結果を公表しました。設定ファイルを短時間だけ改ざんし、すぐ正規の内容へ戻す手口です。ManageEngineのThreat Analysis Lab（METAL）も16日に共同調査の分析を公開しています。

本記事の情報確認日は2026年10月17日です。攻撃の調査対象は2026年4〜7月で、10月17日に新たに侵入が起きたという速報ではありません。既存のnpm依存関係やバックアップ保存先の解説とは異なり、今回はデスクトップソフトの更新・通知経路が悪用された実例を扱います。出典：GTIG・Mandiant：短時間の更新基盤改ざんに関する調査、METAL：AOMEI Backupperサプライチェーン侵害の分析。

数分後に確認すると正常に戻っている

GTIGが確認した改ざんは5〜10分の短い時間帯に行われました。その間に更新を確認した端末へ不正な指示を渡し、前後の端末には正規の内容を返していたと報告しています。配布されたものにはCROSSROADとSHINYROADと名付けられたマルウェアが含まれます。出典：GTIG・Mandiant：Campaign Overview。

この事例で重要なのは、調査する時刻と実際にファイルを受け取った時刻が違うことです。警告を受けて配布URLを開き、安全そうなファイルが返ってきても、それは今の応答を確認しただけです。過去の端末が同じ内容を取得したことの証明にはなりません。

本サイトの提案は、判断の軸を「配布元が今どう見えるか」だけから、「その端末がその時刻に何を受け取り、何を実行したか」へ広げることです。ファイル名やドメインだけでなく、取得時刻、保存先、起動した親プロセス、通信先をつなげて記録します。

攻撃されたのは更新を決める設定の経路

METALは、AOMEI Backupperが取得する二つの設定ファイルを説明しています。down_html.iniが取得するパッケージとチェックサムを示し、Notifycfg.iniが通知側の動作を指示します。設定の暗号学的な認証がなく、パッケージを検査する値も同じ未認証の設定に含まれていたと報告しています。出典：METAL：The delivery mechanism。

一般論として、ファイル本体と検査用の値を攻撃者が両方書き換えられるなら、両者が一致しても配布の正当性は確かめられません。荷物と、その荷物に同封された自己申告の確認票だけを照合する状態に似ています。これは説明用の例えであり、今回の攻撃で暗号そのものが破られたという意味ではありません。

通信がHTTPSであることも、配布元のサーバー内にある内容の正当性とは別の確認です。通信相手や経路を保護する仕組みと、取得した設定・コードを誰が承認したかを検証する仕組みを分けて考えます。公式の場所から受け取ったという事実だけで、実行を無条件に許可しない設計が必要です。

調査で見えたことを全利用者へ広げない

METALが記録した経路は、AOMEIのプロセスが展開した領域から署名のない実行ファイルが起動し、正規の管理ツールと攻撃用の部品が組み合わされるものでした。実行権限は起動元のAOMEIプロセスに依存すると説明しています。また、通常のソフトウェア脆弱性を突くことなく、通知コンテンツの仕組みが悪用されたとしています。出典：METAL：Executive summaryとThe investigation。

この記述を「インストールしている端末はすべて感染」「同じ製品名の実行ファイルはすべて不正」とは読み替えられません。一方、CVE番号に対する通常のパッチ確認だけで調査が完結するとも限りません。導入の有無、当時の稼働、取得・実行の記録、侵害の兆候を分けて評価してください。

本稿では、日本での被害を確認したとは述べません。攻撃者のAI利用も、参照した一次資料だけでは確認できません。AIという言葉を付けて一般化するのではなく、実際に報告された更新経路と端末の挙動を点検の対象にします。

Webサイトを管理する端末も確認対象になる

次は本サイトが考えるWeb運営への影響です。公開サーバーにAOMEI製品を入れていなくても、制作・保守担当のWindows端末が利用している場合があります。その端末からCMS、SFTP、クラウド、ソース管理へ接続できるなら、端末の状態はサイトの管理経路にも関わります。これは今回の調査で全サービスへの侵入が実証されたという意味ではありません。

説明用の仮想例として、WordPressのテーマを開発するPCでバックアップソフトを動かし、同じPCに本番接続用の秘密鍵を保存している構成を考えます。侵害が疑われたときには、ソフトを削除するだけでなく、そのPCから操作できたサービスを調べる必要があります。

ただし、権限があったことと実際に悪用されたことは別です。秘密鍵、保存済みセッション、クラウドの資格情報、パッケージ公開権限などを整理し、ログと照合して封じ込めの範囲を決めます。全サービスへ一律の変更をかける前に、影響と業務停止を調整できる担当者へ引き継いでください。

最初に残すのは現在の画面より当時の記録

GTIGは、配信サーバーの是正だけでは、既に不正な更新を受け取った端末は復旧しないと指摘しています。AOMEIは7月29日の回答で、是正措置を取ったと説明したということです。また、調査では端末のキャッシュと当時の通信記録を重視しています。出典：GTIG・Mandiant：Remediation and Hardening。

以下は、組織の対応担当者と進めるための本サイトの整理です。不審な端末で新たな検証ファイルを実行したり、攻撃用のURLへ接続したりする必要はありません。端末を消去する前に、調査に必要な記録と隔離方法を相談します。

対象端末と利用者、導入していた製品、確認できる稼働期間を一覧にする。
警告の発生時刻、プロセスの親子関係、実行ファイルの場所と署名情報を保全する。
設定のキャッシュや取得済みファイルは、元の場所と取得時刻が分かる形で保全する。
EDR、プロキシ、ファイアウォールなどの記録を同じ時間帯で照合する。
調査に使えるログの保持期間と、記録が存在しない期間を明示する。

今から過去のログを作ることはできません。4〜7月の記録が残っていない場合は、その不足を安全の根拠にせず、端末の現状、保持している監視データ、提供元への照会で評価を補います。「未検出」「記録なし」「未調査」は別の状態として報告してください。

署名のある実行ファイルだけで警告を閉じない

一次資料は、正規のソフトウェアが攻撃の経路に組み込まれる事例を示しています。しかし、正規ツールを見つけたという事実だけで不正と決めるのも誤りです。業務で承認している導入か、どこから起動されたか、どの部品を読み込んだかを確認します。

たとえば、更新処理の直後に予期しない実行ファイルが起動していたなら、親プロセスが有名な製品だからという理由だけで例外登録しないようにします。逆に、署名がないという一点だけで即座に全ファイルを削除すると、証拠や正常な業務ファイルを失う可能性があります。検知結果は調査の起点として扱います。

IOCの照合にも限界があります。既知のハッシュや通信先への一致は有力な手掛かりですが、不一致はすべての変種を否定しません。記事へ危険な接続先をクリック可能な形で転載する代わりに、調査担当者は一次資料のIOC一覧を利用し、取得日を記録してください。

独自の更新機能を作る開発者が見直したい境界

自作のデスクトップツールや社内エージェントにも、JSONで配布先を受け取り、ZIPを展開して実行する仕組みがあります。以下は今回の事件を自社設計へ応用する提案であり、特定製品の修正版が備える機能を断定するものではありません。

設定と配布物の正当性を、変更可能な配布サーバーだけに依存せず検証する。
検証失敗時は古いコードや未検証の取得先へ自動で迂回せず、安全に停止して通知する。
更新の実行機能と、広告・通知を描画する機能の権限を分ける。
取得、検証、展開、実行の各段階と対象の識別情報を追跡できるようにする。

設計を具体化する際の参考に、The Update Framework（TUF）があります。公式概要は、信頼する鍵、ファイルのハッシュ、メタデータへの署名、版番号、有効期限などを使って更新の正当性を確認する枠組みを説明しています。鍵の侵害や古い更新を返す攻撃も考慮する設計です。出典：TUF公式：更新の正当性を確認する仕組み。

TUFの名前を採用するだけで完成するわけではありません。鍵をどこで保管し、誰が配布を承認し、失効や期限切れをどう処理するかが必要です。通常の新しい更新が通る試験だけでなく、不正な署名、古いメタデータ、想定外の配布先を拒否する試験も計画します。本記事では実装や再現試験は行っていません。