2023年7月4日の朝、取扱貨物量が日本一の 名古屋港 で、5つのコンテナターミナルと集中管理ゲートを統合管理する 名古屋港統一ターミナルシステム（NUTS） が停止しました。システム専用のプリンターからはランサムウェア LockBit の脅迫文が印刷され、物理サーバー基盤8台と仮想サーバー45台がすべて暗号化されていました。コンテナの搬出入は7月6日夕方まで約2日半止まり、船舶37隻の荷役が遅れ、約2万本のコンテナに影響が出ました。トヨタ自動車は輸出向け部品の梱包拠点を止めています。
国土交通省は「コンテナターミナルにおける情報セキュリティ対策等検討委員会」を設置し、2023年9月の中間取りまとめで、侵入経路と問題点を整理しました。本記事では、この資料をもとに各段階を整理します。
■ この記事のまとめ
- 初期侵入：保守用 VPN 装置からの侵入が最も可能性が高い。緊急時にすぐ接続できるよう 接続元 IP を制限しておらず、ID とパスワードが合えば誰でも接続できた。VPN 装置と物理サーバーには 数か月前に公表された脆弱性が未対応 だった（製品名・CVE は非公表）
- 拡大：アプリケーション経由ではなく、物理サーバー基盤（8台）への直接攻撃 と見られる。基盤上の仮想サーバー45台を含めてすべて暗号化され、システムが起動不能に
- 影響：7月4日6:30に停止、7:30に脅迫文が印刷。7月6日18:15に全ターミナル再開。船舶37隻、コンテナ約2万本に影響
- 復旧の難しさ：バックアップは直近3日分・本番環境のみ。復元した仮想サーバーからトロイの木馬など132件のマルウェアを検知し、駆除が必要になった。ウイルス対策は OS 付属のソフトのみ、VPN のログは取得対象外で、経路は断定できていない
- 分類：リモートアクセス装置を起点とする人手によるランサムウェア攻撃（LockBit）、重要インフラ（港湾）の停止
概要
| 項目 | 内容 |
|---|---|
| 被害システム | 名古屋港統一ターミナルシステム（NUTS）。運営は名古屋港運協会 |
| 発生 | 2023年7月4日 6:30ごろ停止 |
| ランサムウェア | LockBit（脅迫文による） |
| 侵入経路（推定） | 保守用 VPN 装置。接続元 IP 制限なし、数か月前に公表された脆弱性が未対応 |
| 他の可能性 | USB メモリによる持ち込み、港運事業者とのネットワーク連携（NAT）経由。中間取りまとめ時点で精査中 |
| 暗号化 | 物理サーバー基盤 全8台、仮想サーバー 全45台 |
| 検知されたマルウェア | 復元した仮想サーバーからトロイの木馬120、マルウェア4、その他8 |
| 停止期間 | 7月4日 6:30 〜 7月6日 18:15（全ターミナル再開） |
| 影響 | 船舶37隻の荷役遅延（最大24時間程度）、コンテナ約2万本、トヨタ自動車の4拠点の稼働停止 |
| 攻撃の分類 | 外部リモートサービス・既知脆弱性の悪用、ハイパーバイザー（物理サーバー基盤）ごとの暗号化 |
事件の時系列
| 日時 | 出来事 |
|---|---|
| 7月4日 6:30ごろ | NUTS の作動停止を確認 |
| 7:15ごろ | システム保守会社とシステム開発会社に調査を依頼 |
| 7:30ごろ | システム専用のプリンターからランサムウェアの脅迫文が印刷される |
| 8:15ごろ | サーバーが再起動できないことが判明 |
| 9:00ごろ | 愛知県警サイバー攻撃対策隊に連絡。ランサムウェア感染の可能性を指摘される |
| 10:30ごろ | 物流の早期再開のため、システム復旧を優先すると判断 |
| 14:00ごろ | 物理サーバー基盤と全仮想サーバーの暗号化が判明 |
| 7月5日 2:00ごろ | 物理サーバー基盤 全8台が復旧、仮想サーバー45台の復元を開始 |
| 12:00ごろ | 名古屋港運協会がランサムウェア感染を公表。仮想サーバーの復元完了、ウイルスチェック開始 |
| 21:00ごろ | 復元した仮想サーバーからウイルスを検知、駆除が必要と判断 |
| 7月6日 2:00ごろ | トロイの木馬120・マルウェア4・その他8を検知し、駆除を開始 |
| 7:15ごろ | 駆除終了。バックアップから CS・CTMS を復元したが、連携に障害 |
| 14:15ごろ | 連携障害が解消 |
| 15:00〜18:15 | 準備の整ったターミナルから順次再開。18:15に全ターミナルの作業を再開 |
| 9月29日 | 国交省の検討委員会（第2回）が中間取りまとめを示す |
① 初期侵入：IP 制限のない保守用 VPN
NUTS は、港運事業者のターミナル運営を支える基幹システム（CS：Control System）と、ターミナル管理システム（CTMS）などで構成され、データセンター内の物理サーバー基盤と仮想サーバーで動いていました。保守事業者がリモートで保守するための 保守用 VPN が外部との接点になっていました。
中間取りまとめは、考えられる感染経路として①VPN 装置、②USB メモリによる持ち込み、③港運事業者とのネットワーク連携（NAT）経由の3点を挙げたうえで、VPN 装置からの侵入と見るのが適切 としています。根拠として次の事実が確認されています。
- 保守用 VPN は、緊急時にすぐ対応できるよう 接続元 IP アドレスを制限しておらず、ID とパスワードさえ合致すればインターネット上の誰からでもアクセスできる 状態だった（T1133、T1078）
- VPN 装置と物理サーバーについて、数か月前から脆弱性が公表されていたのに未対応 だった（T1190）
- VPN 装置のログは取得対象になっていなかった。システム内部のアクセスログは暗号化され、経路を断定できなかった
VPN 装置の製品名、脆弱性の CVE 番号、認証情報が使われたのか脆弱性が直接悪用されたのかは公表されていません。中間取りまとめは「VPN 経由以外での侵害の可能性についても精査すべき」としています。
② 拡大：物理サーバー基盤への直接攻撃
被害の特徴は、8台の物理サーバーがすべて暗号化され、システムが起動しなくなっていた ことです。中間取りまとめは、ここから「アプリケーション経由ではなく、サーバ部への直接的な攻撃が行われた可能性が高い」と判断しています。仮想化基盤（ハイパーバイザー）が暗号化されれば、その上の仮想サーバーはまとめて動かなくなります。実際、14時ごろには物理サーバー基盤と 全仮想サーバー（45台） の暗号化が判明しました（T1486）。
仮想化基盤の製品名は公表されていません。なお LockBit は、Windows だけでなく Linux や VMware ESXi を暗号化するモジュールを持つことが、米 CISA などの共同勧告で指摘されています（CISA AA23-165A）。内部での権限取得や横展開の手法も公表されていません。
防御側の対策は、基幹 OS 付属のセキュリティ対策ソフトのみ でした。中間取りまとめは「NUTS に求められるセキュリティレベルとしては不十分」としています。
③ 影響と復旧：バックアップからもマルウェア
7時30分ごろ、システム専用のプリンターから LockBit の脅迫文 が印刷されました。名古屋港運協会は、物流の早期再開を優先してシステム復旧を進めます。7月5日未明に物理サーバー基盤8台を復旧し、昼までに仮想サーバー45台をバックアップから復元しましたが、21時ごろ、復元した仮想サーバーからウイルスが検知 されました。最終的にトロイの木馬120個、マルウェア4個、その他8件が見つかり、駆除してから CS・CTMS を復元・連携し、7月6日18時15分に全ターミナルを再開しています。
バックアップについて、中間取りまとめは次の問題を指摘しています。
- 直近3日分のみ で、感染前のクリーンな状態に戻せなかった（バックアップの中にもマルウェアがあった）
- 本番環境のみ が対象で、開発・評価環境は対象外。容量とコストを抑えた結果、かえって復旧の時間と費用が増えた
- ログ がバックアップの対象外で、暗号化により原因分析ができなかった
荷役を行う船舶37隻に最大24時間程度の遅れが出て、約2万本のコンテナの搬入・搬出に影響しました。トヨタ自動車は部品の積み込みができず、愛知・岐阜の輸出向け部品梱包拠点4か所の稼働を止めています。
初動対応の課題
中間取りまとめは、技術面以外の問題も挙げています。災害用の BCP はあったものの、システム障害（サイバー攻撃）を対象とした BCP がなかった こと、初動で連絡したのがシステム保守会社と開発会社だけで、サイバーセキュリティの専門家に相談していなかった ことです。保守会社・開発会社はシステムの専門家であっても、侵害の調査や、復旧後の安全性の判断の専門家ではありません。
MITRE ATT&CK との対応
| 段階（戦術） | 技術 | 本件での事実 |
|---|---|---|
| 初期アクセス | T1133 External Remote Services／T1078 Valid Accounts | 保守用 VPN。接続元 IP 制限なし、ID/PW が合えば誰でも接続可能 |
| 初期アクセス | T1190 Exploit Public-Facing Application（可能性） | VPN 装置の数か月前に公表された脆弱性が未対応 |
| 権限昇格・横展開 | （詳細非公表） | 物理サーバー基盤への直接攻撃と推定。物理サーバーの脆弱性も未対応 |
| 影響 | T1486 Data Encrypted for Impact | 物理サーバー8台・仮想サーバー45台を暗号化 |
| 影響 | ― | 専用プリンターから脅迫文を印刷 |
| 永続化 | （詳細非公表） | 復元した仮想サーバーからトロイの木馬など132件を検知 |
本事件を未然に防ぐために必要な予防策
中間取りまとめが「緊急に実施すべき対応策」として挙げた内容に沿って整理します。
外部接続（VPN）を固める
- 接続元 IP の限定と多要素認証：「緊急時にすぐつなげる」ための例外が、そのまま攻撃者の入口になりました。保守事業者の固定 IP に限定し、知識・所持・生体のうち複数の要素を求める認証にします。
- 不正ログイン試行の検知とログの外部保存：VPN 装置のログを定期的に取得し、システム外に保存します。入口のログがなければ、侵入経路は分かりません。
- 侵害された機器は交換する：攻撃を受けたネットワーク機器は、外部から制御可能な状態になっている可能性があるため、新品への交換が望ましいとされています。
サーバー・基盤を守る
- ハイパーバイザーを含めた脆弱性管理：仮想化基盤の脆弱性は、上で動くすべての仮想サーバーに影響します。管理インターフェースを分離したネットワークに置き、修正を早期に適用します。
- OS 付属の対策ソフトだけに頼らない：EDR など、振る舞いを検知できる対策を導入します。
復旧できるようにする
- バックアップの世代と範囲：システムプログラムなど更新頻度が低いデータは長期間、コンテナ情報など動的なデータは高頻度で取得します。開発・評価環境とログもバックアップの対象にし、オフライン・イミュータブルな保管先を持ちます。
- サイバー攻撃を想定した BCP と専門家との関係：システム停止時の手作業での荷役手順、関係者への連絡手順、セキュリティ専門家への相談窓口を事前に決めておきます。
この事件を受けて、港湾運送事業は経済安全保障推進法の「特定社会基盤事業」（基幹インフラ）に追加され、国交省は港湾分野の情報セキュリティ確保に係る安全ガイドラインを整備しています。
まとめ
名古屋港の事件は、「外とはつながっていない」と考えられていた基幹システムにも、保守のための VPN という入口があったことを示しました。緊急時の利便性のために IP 制限を外した VPN、数か月放置された脆弱性、OS 付属だけのウイルス対策、3日分しかないバックアップ――どれも珍しい弱点ではありません。物理サーバー基盤ごと暗号化されると、上で動くすべてが止まり、バックアップの中に潜んだマルウェアまで掃除しなければ再開できません。重要インフラを支えるシステムほど、保守経路と復旧手段の設計が問われます。
■ メモ
本記事は、国土交通省「コンテナターミナルにおける情報セキュリティ対策等検討委員会 中間取りまとめ」（2023年9月）、国交省港湾局の事案事例集、報道をもとに、公表された範囲の事実を整理したものです。VPN 装置・仮想化基盤の製品名、脆弱性の CVE、内部での拡大手法は公表されていません。
参考資料
- 国土交通省「名古屋港のコンテナターミナルにおけるシステム障害を踏まえ緊急に実施すべき対応策について（中間取りまとめ）」（PDF）
- 国土交通省「中間取りまとめ（概要）」（PDF）
- 国土交通省港湾局「港湾分野における情報セキュリティ確保に係る安全ガイドライン 事案事例集」（PDF）
- CISA「Understanding Ransomware Threat Actors: LockBit（AA23-165A）」
- トレンドマイクロ「名古屋港の活動停止につながったランサムウェア攻撃～今一度考えるその影響と対策」
- MONOist「サイバー攻撃で止まった名古屋港、必要なのは驚くほどシンプルな対策」
- MITRE ATT&CK
ほかの事件の解説は「日本のサイバーセキュリティ事件まとめ」から読めます。
