「会計ソフトのアップデートで感染が広がるって、どうすれば防げたんでしゅか?」 「ランサムウェアと言いながら、復号できないって本当でしゅか?」
NotPetyaってよく聞くでしゅけど、普通のランサムウェアとは違うんでしゅか? Maerskが45,000台のPCを再インストールしたって聞いて、震えてましゅ……。
ランサムウェアを装った純粋な破壊兵器だな。 身代金を払っても絶対に復号できない構造になっている。 目的は金儲けではなく、インフラそのものを壊滅させることだった。
2017年6月27日、ウクライナの会計ソフト「M.E.Doc」のアップデート経由で拡散を開始したNotPetya(ノットペトヤ)は、数時間のうちにヨーロッパ・北米・アジアの大企業のシステムを次々と機能停止させました。 ランサムウェアに見せかけながら実態はシステムを永久に破壊する「ワイパー型」マルウェアであり、その総被害額は100億ドル超に上ると複数の政府・研究機関が推計しています。 この記事では、NotPetya攻撃がなぜこれほど急速に拡散したのか、そして世界中の企業が受けた壊滅的な被害から何を学ぶべきかを解説します。
NotPetya攻撃がサプライチェーン経由でどのように世界中へ広がったか
NSAの攻撃ツールを流用した、パッチ済み環境でも拡散する仕組み
Maersk・Merck・FedExを壊滅させた、100億ドル超の被害実態
サプライチェーンリスク管理とBCP(事業継続計画)の実践的な設計指針
本記事を最後まで読むことで、NotPetya事件が現代のセキュリティ設計に残した教訓を体系的に整理できます。 「信頼したソフトウェア経由の感染」という想定外のシナリオに備えるための具体的な対策を、自分の現場に持ち帰れるはずです。
目次
NotPetya攻撃とは何だったのか
NotPetya事件を特徴付けるのは、サプライチェーン侵入とワイパー型マルウェアの組み合わせです。 見た目はランサムウェアでしたが、設計の根本はデータ破壊とシステム機能停止にありました。
会計ソフト経由でウクライナから世界へ広がった感染
NotPetyaの初期感染源は、ウクライナで多くの企業が使用していた会計ソフト「M.E.Doc(エムイードック)」のアップデートサーバーです。 攻撃者はM.E.Docの開発会社Intellect Serviceのサーバーに侵入し、正規のソフトウェアアップデートにNotPetyaを混入させました。 2017年6月27日にアップデートを受け取った端末が自動的に感染し、そこからネットワーク全体へ拡散しました。
感染拡大の時系列を整理します。
日時(現地時間) 出来事 2017年6月27日 午後1時頃 M.E.Docアップデート経由でウクライナ国内で感染拡大開始 2017年6月27日 午後1〜2時 ヨーロッパの多国籍企業が次々とシステム障害を報告 2017年6月27日 午後3時頃 北米・アジアの拠点にも感染が到達 2017年6月28日 ウクライナ政府機関、空港、銀行が被害を公表 2018年2月 米国・英国政府がロシア軍による攻撃と公式認定(後にGRU=ロシア軍参謀本部情報総局の関与が確認される)
引用元:米国土安全保障省(CISA)、英国立サイバーセキュリティセンター(NCSC)の公式声明
ソフトのアップデートで感染するって、何を信用すればいいんでしゅか……?
それがサプライチェーン攻撃の本質だ。 使い続けている信頼済みソフトのアップデートなら、誰も疑わない。 だからこそ、最も危険な侵入経路になる。
ランサムウェアを装った「ワイパー型」破壊マルウェアの実態
NotPetyaはシステム起動に必要なMBR(マスター・ブート・レコード)を上書きし、ファイルを暗号化した後に「身代金を支払え」という画面を表示しました。 しかし、復号に必要なInstallation IDは各端末固有のランダム値であり、攻撃者のサーバーに送信される仕組みにはなっていませんでした。 身代金を払っても攻撃者はデータを復元できません。設計上、初めから復号する意図がなかったのです。
研究者らがNotPetyaを「ワイパー型マルウェア(Wiper)」と分類する根拠は以下の通りです。
MBRを上書きすることでOSが起動不能になる
暗号化されたファイルのInstallation IDが攻撃者サーバーと紐付いていない
感染端末に固有の復号鍵が生成・保存される仕組みがない
身代金要求画面はダミーであり、実際のランサムウェアとしての機能を持たない
引用元:Kaspersky Lab, “ExPetr/Petya/NotPetya is a Wiper, Not Ransomware”(2017年6月)
ランサムウェアは金儲けが目的だから、復号機能が必要だ。 だがNotPetyaには最初から復号機能がない。 目的は金ではなく、システムの完全破壊だということだ。
なぜこれほど急速に拡散したのか
NotPetyaが数時間で世界規模の被害を引き起こせた背景には、複数の攻撃手法を組み合わせた「多段階の感染チェーン」がありました。 既知の脆弱性への対応が済んでいた組織でも、別の経路で感染が広がる設計になっていた点が特に深刻でした。
EternalBlueとMimikatzが組み合わさった多段階の攻撃チェーン
NotPetyaは以下の複数の攻撃手法を組み合わせて感染を拡大させました。
EternalBlue(CVE-2017-0144) :米国家安全保障局(NSA)が開発し、2017年4月にShadow Brokersによって公開されたSMBv1の脆弱性を悪用するエクスプロイト
EternalRomance(CVE-2017-0145) :EternalBlueと同様にSMBv1を標的とした別のNSAエクスプロイト
Mimikatz :メモリから認証情報(パスワードハッシュ)を盗み出すツール
感染した端末は、まずMimikatzでメモリから管理者の認証情報を取得します。 次に、その認証情報を使ってWMI(Windows Management Instrumentation)やPsExecで隣接端末に接続し、NotPetyaを実行します。 EternalBlueはSMBv1の脆弱性を悪用して、認証なしでも感染を拡大できる追加の経路として機能しました(引用元:Talos Intelligence Group, “The MeDoc Connection”(2017年7月)、ESET Research)。
パッチ済み端末でも止められなかった横展開の仕組み
EternalBlueはWannaCry(2017年5月)で既に悪用されており、多くの組織がMicrosoft MS17-010のパッチを適用済みでした。 しかし、NotPetyaは「Mimikatz+WMI/PsExec」の経路も持っていたため、EternalBlueが通じない端末でも感染が拡大しました。 ネットワーク内に一台でも感染端末があれば、パッチ済みの他の端末にも管理者認証情報経由で感染が及ぶ構造だったのです。
これが示す教訓は、「パッチを当てれば安全」という思考の限界です。 横展開(ラテラルムーブメント)を前提とした設計——つまりネットワークセグメンテーションと最小権限——がなければ、パッチ対応だけでは被害を止められません。
パッチを当ててても感染するって、じゃあ何をすればよかったんでしゅか?
ネットワークセグメンテーションと最小権限の徹底だ。 感染が広がるのは、一つの管理者アカウントがネットワーク全体にアクセスできるフラットな設計が多いからだ。 分けることで、被害範囲を限定できる。
世界規模の被害と復旧コスト
NotPetyaは単一の攻撃として、史上最大規模の経済損失をもたらしたサイバー攻撃と評価されています。 複数の政府・研究機関の推計によれば、被害総額は100億ドル(約1兆5,000億円)超に達するとされています。
損害総額100億ドル超——大企業が受けた壊滅的な打撃
被害を受けた主要企業の損失額は以下の通りです。
企業名 業種 報告された損失額 Merck(メルク) 製薬 約8億7,000万ドル TNT Express(FedEx傘下) 物流 約4億ドル A.P. Møller-Maersk 海運 約3億ドル Mondelez International 食品 約8,400万ドル(追加回復費用) Reckitt Benckiser 消費財 約1億2,900万ドル
引用元:各社の有価証券報告書・公式声明、White House Press Briefing(2018年2月)
事業の中断が長引くほど、損失は膨らむ。 Maerskはコンテナ輸送を数日間止めることになり、世界中の港湾で荷受けができない状態が続いた。
メルクって医薬品会社でしゅよね? 製造ラインまで止まったんでしゅか?
そうだ。製造・販売システムが機能停止し、一部ワクチンの製造ラインも停止した。 その影響で、米国政府からワクチンの緊急融通まで受けることになった。
Maerskの復旧から見えた「システム全損」の現実
世界最大の海運会社A.P. Møller-Maerskの復旧作業は、大規模サイバー攻撃からの回復がいかに困難かを示す象徴的な事例として知られています。 後に公開された情報によれば、Maerskは10日間で以下の規模の復旧作業を実施しました。
再インストールしたPCの台数:約45,000台
再構築したサーバーの台数:約4,000台
再展開したアプリケーション数:約2,500本
世界各地から集結した応援IT要員:約200人
さらに深刻だったのは、Active Directory(企業全体の認証基盤)のバックアップが唯一、ガーナのオフィスに残っていた点です。 そのオフィスが停電に見舞われていたため、データ復旧の作業は停電復旧と並行して進めるしかありませんでした。 ほぼ偶然が重なった幸運がなければ、復旧は数週間以上延びていた可能性があります(引用元:Wired誌, “The Untold Story of NotPetya”(2018年8月))。
セキュリティエンジニアへの教訓
NotPetya事件は「サプライチェーンへの信頼」「ネットワーク設計の甘さ」「バックアップの不備」という三つの失敗が重なって最悪の結果を生んだ事例です。 一つひとつの対策は既知のベストプラクティスですが、それが実際に機能する状態に保てているかどうかが問われます。
サプライチェーンリスクをどう評価・管理するか
「信頼できるベンダーからのアップデート」を無条件で適用することは、攻撃者にとって格好の踏み台を提供することになります。 特に業務に深く組み込まれたソフトウェアは、更新のたびに大量の端末へ同時配信されるため、一点突破で組織全体を侵害できます。
サプライチェーンリスクを管理するための実践的なアプローチを整理します。
ソフトウェアサプライチェーンの可視化 :利用するソフトウェアのサプライヤーを一覧化し、重大な信頼ポイントを特定する
アップデートの段階的展開 :全端末への一括適用ではなく、テスト環境→一部端末→全端末という段階的なロールアウトを設ける
ソフトウェアの署名検証 :コードサイニング証明書の検証プロセスを導入し、改ざんされたアップデートを検知する
SBOM(ソフトウェア部品表)の整備 :組織内で使用するソフトウェアの依存関係を把握し、脆弱性情報との照合を自動化する
サプライヤーのセキュリティ評価 :主要ベンダーに対してセキュリティ審査やSOC 2報告書の提出を要求する
引用元:NIST SP 800-161 Rev.1「サイバーサプライチェーンリスク管理の実践」(2022年5月・2024年11月1日更新を含む)
NotPetya以降、サプライチェーンへの攻撃は急増している。 2020年のSolarWinds事件も、同じ手口だ。 「信頼できるソフトのアップデートだから安全」という前提は、もう通じない。
ネットワークセグメンテーションと最小権限で感染拡大を止める
NotPetyaがこれほど急速に組織全体へ広がった大きな理由の一つは、多くの企業が「フラットなネットワーク」を運用していたことです。 一台が感染すれば同一ネットワーク上の全端末へ容易にアクセスできる設計は、横展開(ラテラルムーブメント)を無制限に許します。
効果的な対策として以下が挙げられます。
ネットワークセグメンテーション :業務領域ごとにネットワークを分割し、セグメント間の通信をファイアウォールで制限する
最小権限の原則(PoLP) :管理者アカウントの使用を必要最小限に絞り、日常業務には権限の低いアカウントを使う
SMBv1の無効化 :EternalBlueが悪用するSMBv1プロトコルは現在では不要なため、全端末で無効化する
資産管理の徹底 :ネットワーク上の全端末を把握し、パッチ適用状況を継続的に確認する
引用元:CISA Insights, “Remediate Vulnerabilities for Internet-Accessible Systems”(2021年)
バックアップとBCPがなければ「復旧」は不可能だった
Maerskの事例が示すように、バックアップの品質が復旧の可否と期間を決定します。 Active Directoryのバックアップがガーナのオフィスにしか残っていなかったことは、ほぼ偶然が重なった幸運でした。 この幸運がなければ、Maerskの復旧は10日では終わらなかったはずです。
破壊型マルウェアに備えたバックアップ戦略のポイントは以下の通りです。
3-2-1ルール :3つのコピーを、2種類の異なるメディアに保存し、1つはオフサイト(外部)に置く
エアギャップバックアップ :ネットワークから物理的・論理的に切り離されたバックアップを保持し、マルウェアによる破壊を防ぐ
復旧テストの定期実施 :バックアップを取るだけでは不十分。定期的にリストアテストを行い、実際に復旧できることを確認する
BCP・DRPの整備 :IT担当者が限られた状態でも動かせるオフライン手順書を準備する
優先度別の復旧計画 :業務インパクトに基づいて復旧の優先順位を事前に決めておく
引用元:NIST SP 800-34 Rev.1「情報技術システムのための緊急時計画ガイド」
Maerskって10日で復旧したんでしゅよね? 45,000台のPCって、すごい数でしゅけど……10日って早くないでしゅか?
バックアップがあったからだ。 もし定期バックアップもなく、手順書もなく、応援要員もいなければ、復旧に数ヶ月かかっていたはずだ。 10日で戻れたこと自体が、準備の賜物だった。
まとめ
NotPetya大規模サイバー攻撃は、会計ソフトのアップデートという「信頼されたルート」を通じて侵入し、ワイパー型マルウェアで世界中の企業インフラを機能不全に追い込んだ前例のない事件です。 損害総額100億ドル超という数字は、サイバー攻撃が現代のビジネスに与えるリスクの大きさを端的に示しています。
セキュリティエンジニアとして取り組むべき課題は明確です。 サプライチェーンを可視化してリスクを評価すること。ネットワークをセグメントに分けて感染拡大を抑制すること。そして定期的なリストアテストで「本当に復旧できるバックアップ」を維持することです。 NotPetyaが示した教訓は、対策の「有無」ではなく「機能しているかどうか」を継続的に確認することの重要性です。
NotPetyaで最も被害が小さかった組織は、感染前からネットワーク分離とバックアップ検証を徹底していたところだ。 準備は攻撃が始まってからでは間に合わない。
うちの会社も、サプライチェーンのリスク評価とバックアップのテスト、今すぐ確認してみましゅ! ボス、ありがとうございましゅ!