数分だけの配信サーバー改ざんを「誤検知」で片付けない（UNC7017・AOMEI 事例）

何が起きたか

• GTIG と Mandiant が報告した攻撃者「UNC7017」は、バックアップソフト「AOMEI Backupper」などの配信サーバーの設定を短時間だけ書き換え、不正な更新を配った後に正規の内容へ戻していた。
• 調査期間は 2026 年 4〜7 月。直接確認された改ざんは 3 回で、継続時間は 10 分・6 分・5 分。観測できなかった改ざんがあった可能性もある。
• その間に更新を確認した端末はすべて配布対象。ダウンローダー「CROSSROAD」が環境を確認し、条件に合えばバックドア「SHINYROAD」を入れる。
• 1×1 ピクセルの通知ウィンドウに外部の WebDAV リソースを読み込ませ、Windows の NetNTLMv2 認証応答を攻撃者のサーバーへ送らせる処理もあった。

防御・調査のポイント

1. 配信元を後から確認しても安心材料にならない。 「今ダウンロードしたら正常なファイルだった」は、改ざんが終わった後なら当然そうなる。EDR やアンチウイルスの検知は、まず本物として扱う。
2. 検知した時点の証拠を保全する。 端末に残る更新ソフトの設定ファイル、検知時刻前後のプロキシ・ファイアウォールのログ、ダウンロードされたファイル本体。
3. 一台の検知で終わらせず、期間全体を遡る。 同じソフトを使う全端末について、同じ時間帯の更新通信と、配布されたファイルのハッシュを確認する。報告に掲載された IOC と YARA ルールで、サーバー復旧後も残っているマルウェアを探す。
4. NTLM の外部送信を止める。 社外への SMB（445）・WebDAV 経由の NTLM 認証を出口で遮断し、グループポリシーの「NTLM の制限：リモートサーバーへの送信 NTLM トラフィック」で外向きの NTLM を制限・監査する。NTLM の利用状況は Windows の「Enhanced NTLM auditing」で残っている NTLM 依存を洗い出す で洗い出せる。
5. 更新の真正性を検証する。 署名の検証をしない更新機構を持つソフトは、更新を社内の配布基盤経由にする、更新を自動で入れず検証してから展開する、などで直接取りに行かせない。

関連

• ソフトウェアサプライチェーン攻撃対策ガイド

出典

• @MalwareBibleJP · 2026-10-22
• Google Cloud（GTIG／Mandiant）「Investigating Ephemeral Supply Chain Tampering」: cloud.google.com