国家支援の攻撃者がNotepad++のアップデートをハイジャック
2025年12月、国家支援の攻撃者がNotepad++のアップデートメカニズムをハイジャックしたことが確認されました。攻撃者は、ソフトウェアプロジェクトの共有ホスティングサーバーを侵害し、正規のアップデートトラフィックを傍受して悪意のある更新を配信しました。この攻撃は、特に東アジアの通信および金融サービス業界をターゲットにしており、攻撃者は中国の国家支援の脅威アクターであるZirconiumに関連付けられています。Notepad++のアップデート機構は、バージョン8.8.8以降に強化され、今後のバージョンではダウンロードファイルの整合性と認証が検証されるようになります。
メトリクス
このニュースのスケール度合い
インパクト
予想外またはユニーク度
脅威に備える準備が必要な期間が時間的にどれだけ近いか
このニュースで行動が起きる/起こすべき度合い
主なポイント
- ✓ 国家支援の攻撃者がNotepad++のアップデートメカニズムをハイジャックし、悪意のある更新を配信しました。
- ✓ 攻撃は特に東アジアの通信および金融サービス業界をターゲットにしており、Zirconiumという中国の脅威アクターに関連付けられています。
社会的影響
- ! この攻撃は、特に通信および金融サービス業界におけるサイバーセキュリティの脆弱性を浮き彫りにしました。
- ! 多くの組織がNotepad++を使用しているため、攻撃の影響は広範囲に及ぶ可能性があります。
編集長の意見
解説
国家支援がNotepad++の更新経路を乗っ取り——東アジアの通信・金融を狙う供給網侵害の現実
今日の深掘りポイント
- 共有ホスティングを起点に、正規アップデート経路を悪性配信へ“すり替える”サプライチェーン型攻撃が成立しています。更新は最短・最高信頼の侵入路になり得ます。
- 標的は東アジアの通信・金融。広域配布ツールを使い、狭い標的へ段階的に絞り込む「広く撒いて狭く刺す」戦術がうかがえます。
- 検証機構が弱い更新プロトコルは「fail-open」的に振る舞いがちです。8.8.8以降で整合性・認証検証が入る見込みですが、企業側も受け手の検証を二重化すべきです。
- いま必要なのは、アップデート元の真正性検証、更新経路のゼロトラスト化(許可リスト・証明書検証・署名必須化)、およびNotepad++実行・更新プロセスの横展開ハンティングです。
- MITRE ATT&CKでは、Supply Chain Compromise(T1195)とCompromise Client Software Binary(T1554)、Subvert Trust Controls(T1553)、Adversary-in-the-Middle(T1557)などが核心のタクティクスです。
はじめに
「更新さえすれば安全」という常識に、また一つ例外が刻まれました。2025年12月に確認されたNotepad++のアップデートメカニズムのハイジャックは、共有ホスティングサーバーの侵害を足場に、正規の更新トラフィックを乗っ取って悪性更新を配信するという、もっとも信頼されやすい導線を悪用した攻撃です。報道では、中国の国家支援アクターZirconiumに関連付けられ、東アジアの通信・金融を狙ったとされています。広く使われる開発者向けツールの更新経路が攻撃に転用されると、SOCが前提にしてきた“正常な通信”の仮面をまとって侵入が成立します。定番ツールほど、攻撃者の効率は高まります。ここをどう守り直すかが、今回の肝です。
参考: Help Net Securityの報道(2026-02-02)では、侵害は2025年6月に始まり、9月2日までホスティング環境が汚染された可能性、12月にハイジャックが確認されたこと、8.8.8以降でアップデート検証強化予定が言及されています。Help Net Security
深掘り詳細
事実関係(確認できていること)
- タイムライン
- 2025年6月: 共有ホスティングサーバーの侵害が発生。
- 2025年9月2日: この時点まで侵害状態が継続。
- 2025年12月: Notepad++のアップデートメカニズムのハイジャックが確認。
- 手口
- 正規のアップデートトラフィックを傍受・改変する形で悪性更新を配信。
- 更新経路の検証が不十分だったバージョン系列を悪用。
- 標的と属性
- 東アジアの通信および金融サービス業界を主標的とする選択的攻撃。
- Zirconium(中国の国家支援アクター)との関連付けが報道で示唆。
- 開発側の対応
- Notepad++は8.8.8以降でアップデート検証を強化し、ダウンロードファイルの整合性と認証を検証する計画。
編集部のインサイト
- 更新は「特権的なトラフィック」です
- 多くの企業では、アップデート関連の通信は許可リスト化され、EDRの例外対象やプロキシの透過許可対象に入りがちです。この構造が、攻撃側に“最短距離の侵入路”を提供します。更新プロセスは管理者権限で動くこともあり、得られる初期権限の質が高いのが特徴です。
- 「広域配布 × 選択的有効化」の戦術
- オープンソースの一般ツールは裾野が広い一方、攻撃面で“どの端末が本命か”は更新後の段階で判定できます。IPジオ、組織名、ドメイン参加、利用プロセスなどで標的を後から絞り、二段階で本命に“刺す”。この戦術は東アジアの特定業種を狙う今回の文脈に整合的です(仮説であり、詳細な配布条件は公開情報に依存します)。
- 技術論点は「検証の多層化」
- ベンダー側が整合性・署名検証を実装しても、企業側の実運用でプロキシ代替配布、キャッシュ、証明書インターセプトなどが入ると、思わぬ“穴”が残ります。更新の真正性確認は、アプリ側(アプリ内検証)+OS側(スマートスクリーン、WDAC/AppLocker)+ネットワーク側(FQDN・証明書ピン留めに準ずる検証運用)の三層で締めるのが要諦です。
- ガバナンスの視点
- 「更新を急がせるKPI」と「更新経路の検証を厳格化するKPI」はしばしばトレードオフです。今回のようなケースでは、更新のスピードよりも更新の信頼性担保を優先するフラグ(例: 重要ツールは“準隔離”レポジトリからの社内再配布に限定)が有効です。
見落としがちな論点
- 共有ホスティングの脆弱性は“ベンダーの罪”だけではない
- OSSプロジェクトがコスト面から共有環境を使う現実は変わりづらいです。受け手側が“信頼は検証で稼ぐ”設計に立つことが、サプライチェーン全体のレジリエンスを底上げします。
- ログの粒度
- 更新プロセスのログは“正常”として圧縮・ローテーションされがちです。今回の教訓は、更新モジュールのプロセス生成・親子関係・ネットワーク接続先・署名状態を、最低30~90日保持・相関できるようにしておくことです。
脅威シナリオと影響
以下は公開情報を基に、MITRE ATT&CKに沿って構成した仮説シナリオです。実際のTTPは各社のインシデント調査に依存します。
- シナリオA: 共有ホスティング侵害 → 更新経路の乗っ取り → 段階的ペイロード配信
- Resource Development/Recon: 共有ホスティング環境の調査・資格情報収集(仮説)
- Initial Access: Supply Chain Compromise(T1195)
- Initial Access/Execution: Compromise Client Software Binary(T1554)/ User Executionなしで自動更新
- Defense Evasion: Subvert Trust Controls(T1553)
- Command and Control: Application Layer Protocol – Web(T1071.001)
- Discovery: System Information Discovery(T1082)
- Persistence: Boot or Logon Autostart Execution(T1547)やScheduled Task/Job(T1053)(仮説)
- Credential Access/Lateral Movement: OS Credential Dumping(T1003)、Remote Services(T1021)(仮説)
- Exfiltration: Exfiltration Over C2 Channel(T1041)
- シナリオB: トラフィック改ざん型
- 中間者攻撃により更新クエリを差し替え、正規UIを通過して悪性バイナリを取得
- Adversary-in-the-Middle(T1557)+ Subvert Trust Controls(T1553)
- 影響評価の勘所
- 通信・金融は高価値資格情報・重要業務ネットワークへの横展開リスクが高く、一次侵入からの平均滞在期間の延伸が致命傷になりやすい業種です。更新経路で取られた“正面玄関”はEDRの行動検知ですり抜けやすく、検知はネットワーク側の逸脱や署名不整合の相関に寄りがちです。
MITRE ATT&CK参照:
- Supply Chain Compromise(T1195): https://attack.mitre.org/techniques/T1195/
- Compromise Client Software Binary(T1554): https://attack.mitre.org/techniques/T1554/
- Subvert Trust Controls(T1553): https://attack.mitre.org/techniques/T1553/
- Adversary-in-the-Middle(T1557): https://attack.mitre.org/techniques/T1557/
- Boot or Logon Autostart Execution(T1547): https://attack.mitre.org/techniques/T1547/
- Scheduled Task/Job(T1053): https://attack.mitre.org/techniques/T1053/
- Application Layer Protocol: Web(T1071.001): https://attack.mitre.org/techniques/T1071/001/
- System Information Discovery(T1082): https://attack.mitre.org/techniques/T1082/
- OS Credential Dumping(T1003): https://attack.mitre.org/techniques/T1003/
- Remote Services(T1021): https://attack.mitre.org/techniques/T1021/
- Exfiltration Over C2 Channel(T1041): https://attack.mitre.org/techniques/T1041/
セキュリティ担当者のアクション
優先度順に、現実的で“すぐできること”から中長期施策までを整理します。
-
24~72時間以内(緊急)
- 資産把握
- Notepad++インストール端末の全量特定(ソフトウェア資産DB、EDRインベントリ、SCCM/Intune等)。
- バージョンと導入経路(手動/社内配布/自動更新)をタグ付け。
- 通信監視と遮断
- Notepad++関連プロセスによる外向き通信の監視を強化。既知の正規配布ドメイン以外への接続はアラート化(許可リスト方式)。
- 一時的にNotepad++の自動更新を停止し、手動でベンダーの正規配布元から取得・検証して更新。
- ハンティング(例)
- プロセス作成の相関: 親子関係でNotepad++実行ファイル/更新モジュールからcmd.exe/powershell.exe/wscript.exeなどのスクリプト実行器が起動していないか。
- ネットワーク: Notepad++のインストールディレクトリ配下のプロセスによるHTTP/HTTPSコールアウトを抽出し、通常のアップデート先以外を精査。
- 署名検証: 最近30~90日でNotepad++の更新バイナリの署名状態(無署名/異なる発行者)を棚卸し。
- 検体確保
- 直近に配布された更新ファイルを隔離・ハッシュ化・保存。サンドボックス解析とYARAスキャンを実施(社内/委託)。
- 資産把握
-
1~2週間(是正)
- アップデートのゼロトラスト化
- 重要ツールは社内レポジトリ経由で再配布し、外部サイトからの直接更新を禁止。
- 配布前に署名・ハッシュの二重検証を自動化(CI/CD for IT Ops)。少なくともSHA-256とコード署名の発行者検証を必須化。
- 実行制御
- WDAC/AppLocker等で、Notepad++配下からの子プロセス起動を制限(例: スクリプトエンジンはブロック、例外はハッシュで狭く許可)。
- 管理者権限不要のユーザープロファイル配下への自己更新を禁止(レジストリ/ポリシー)。
- 検知ルール整備
- 「エディタ等の非管理系アプリが認証情報アクセスAPIを叩く」「レジストリRunキー/Scheduled Taskを追加する」など、プロファイル逸脱のルールを追加。
- 更新モジュールによるTLS証明書の異常(発行者・有効期限・SANの不一致)を検知。
- アップデートのゼロトラスト化
-
中長期(耐性強化)
- プロセス設計
- 更新KPIを「速度」から「検証完了率」へリバランス。例: 重要アプリは“検証2段階完了後に展開”をSLO化。
- 監査と可観測性
- 更新プロセスのイベント(プロセス生成、署名状態、ネットワーク、ファイル書き換え)をテレメトリ要件として定義し、90日以上保持。
- 供給網リスク管理
- OSS利用ポリシーに「配布インフラの信頼性評価」と「社内再配布の原則」を明記。共有ホスティングのプロジェクトは“社内プロキシ越しの再署名/再検証”を必須化。
- プロセス設計
最後に、この種の事案では「IOCの収集」が第一義に見えますが、今回は更新経路の悪用という性質上、IOCは流動的で“表層”になりがちです。むしろ「更新という行為のふるまい」を正しく監視・制御することが再発防止の本丸です。更新は信頼の象徴であり、同時に攻撃者の最短ルートです。ここを守り切る設計に切り替えていきたいところです。
参考情報
- 2025年Notepad++のサプライチェーン侵害(Help Net Security, 2026-02-02): https://www.helpnetsecurity.com/2026/02/02/2025-notepad-supply-chain-compromise/
- MITRE ATT&CK(各技法の定義): Supply Chain Compromise T1195 https://attack.mitre.org/techniques/T1195/, Compromise Client Software Binary T1554 https://attack.mitre.org/techniques/T1554/, Subvert Trust Controls T1553 https://attack.mitre.org/techniques/T1553/, Adversary-in-the-Middle T1557 https://attack.mitre.org/techniques/T1557/
背景情報
- i Notepad++のアップデート機構は、バージョン8.8.8以前は十分に強化されておらず、攻撃者が更新元を変更することが可能でした。この脆弱性を利用して、攻撃者は正規のアップデートトラフィックを傍受し、悪意のある更新を配信しました。
- i 攻撃者は、Notepad++のホスティングサーバーに対する侵害を通じて、特定の組織に対して初期アクセスを得ることに成功しました。これにより、ターゲットとなる組織に対して手動での再確認活動が行われました。