「ファームウェアは更新した。それなのに、なぜ攻撃を止められなかったのか」。

ネットワーク機器の脆弱性の話を追っていると、この疑問に行き当たることがあります。更新は対策の基本ですが、更新したという事実だけで、その後に起きるすべての攻撃まで防げるとは限りません。

IPA（情報処理推進機構）が2026年7月31日に公開した「制御システム関連のサイバーインシデント事例12」には、そのことを考える材料になる経緯が整理されています。この記事では、まず公表されている出来事を時系列で確認し、そのあとに、事務所でネットワーク機器を管理する立場から何を読み取れるのかを考えます。

この記事でわかること

  • 更新済みの機器でも、その後に別の脆弱性が問題になった事例の経緯
  • 使っていない機能を外部へ公開したままにすることの意味
  • ファームウェア更新とは別に、異常に気づく仕組みが要る理由

2023年5月、22社がほぼ同時に攻撃を受けた

2023年5月、デンマークのエネルギー関連企業22社が、ほぼ同時に大規模なサイバー攻撃を受けました。いくつかの企業では制御システムにアクセスされ、いくつかの企業は回線を切断した稼働を余儀なくされ、一部の企業ではファイアウォールがダウンして通信不能になりました。ただし、電力供給そのものには問題は生じていません。

攻撃対象になったのは、被害企業が使っていたZyxel社のファイアウォールです。Zyxel社は台湾のネットワーク機器製造会社で、同社のZyWALLはデンマークでは中小規模の重要インフラにおいて広く利用されていました。

第1波で使われたのは、2023年4月にNVD（米国の脆弱性データベース）へ登録されたCVE-2023-28771です。デバイスのユーザー名やパスワードを知らなくても、認証なしに管理者権限でコマンドを実行できるというもので、深刻度はCVSS v3の評価基準で9.8の「緊急」とされました。CVSSは、脆弱性の深刻さを同じ物差しで比べるための評価手法です。

ここで注目したいのが、機器の初期設定です。当時のこのファイアウォールは、VPN利用時を想定してインターネット側にポート（UDP 500）をデフォルトで開く仕様でした。実際にVPNを使っていない場合でも開いた状態だったため、このポートを調べることで攻撃者はターゲット企業を容易に絞ることができたと考えられる、と資料は述べています。

2023年5月11日、攻撃者は16社のファイアウォールに対して悪意あるパケットを送信しました。うち11社のファイアウォールが侵害を受け、管理者コマンドによって現在のユーザー名と設定情報を取得されています。

更新させた11日後に、第2波が起きた

この活動に気づいたのは、被害企業自身ではありませんでした。デンマークの非営利団体SektorCERT（重要インフラに対する脅威を把握するためのセンサーネットワークを運営しています）が異常を検知し、即座にインシデントレスポンスチームを結成して、ファームウェアのアップデートが未適用の企業に連絡し、更新を行わせました。

ところが最初の攻撃から11日後の5月22日、第2波の攻撃が発生します。攻撃者は未知の脆弱性（ゼロデイ脆弱性）を悪用して、任意のシェルコマンドを実行させました。侵害されたファイアウォールは新しいソフトウェアをダウンロードし、Miraiボットネットの一部として動作を始め、米国と香港の企業へのDDoS攻撃に参加していたことが分かっています。

ファームウェアが既に更新されていたにもかかわらず問題が発生したことから、SektorCERTは未知の脆弱性によるものと考え、被害企業にファイアウォールの交換を提案しました。交換のため機器を停止すると、制御ネットワークは他のネットワークから切り離した「アイランド（孤島）モード」での稼働になります。そのため一部の企業では、指令所から発電状況をモニタリングしたり、オンラインでメンテナンスしたりできなくなり、担当者が直接現地へ向かうことになりました。

その2日後、Zyxel社から新たにCVE-2023-33009とCVE-2023-33010が公表されました。どちらも最初の攻撃後にアップデートされたファームウェアにも存在しており、深刻度は「緊急」でした。

この事例から言えないこと

ここで、資料自身が置いている留保を飛ばさずに書いておきます。

IPAはこの事例について、インターネットとの境界に位置する機器の問題を扱ったものであり、事業被害から逆算するリスク分析の観点から見ると、自社の事業被害に直結するシナリオとしては捉えにくい側面がある、としています。そのうえで、主要な被害シナリオの例としてではなく、攻撃シナリオを検討するときの視野を広げるための参考事例として位置付けるのが適切だと述べています。

また本件では、ファイアウォールの管理者権限が窃取されたものの、事業者ネットワーク内部への侵入に関する記述はない、と資料は明記しています。したがって、この事例から社内ネットワークで何が起きたかまでを推し量ることはできません。

「更新しても無駄だった」という読み方も、事実に合いません。第1波では、既知の脆弱性に対して更新が未適用だった企業へSektorCERTが連絡し、アップデートを実施させています。第2波で使われたのは、その時点でまだ公表されていなかった別の脆弱性です。既知の問題への更新と、まだ修正が存在しない問題への備えは、別の対策として並びます。

「更新したか」と「外に何を出しているか」は別の確認

制御システムを持たない会社にとって、この事例で読み替えられる部分はどこでしょうか。

資料が挙げている緩和策のひとつが、不要なサービスをネットワークに露出させないことです。インターネット側で利用できるサービスは、VPNを含めて最小限に制限する、という考え方が示されています。

今回の事例では、VPNを使っていない場合でもVPN用のポートが開いていました。資料は、それが攻撃対象を絞る手がかりになったと考えられる、としています。

ここから確認できるのは、ファームウェアが最新かどうかと、インターネット側へ何を公開しているかは、別々の項目だということです。事務所のルーターやファイアウォールにも、以前使っていた機能、設定作業のときだけ必要だった機能、いまは誰も使っていないVPNが残っていることがあります。SSL-VPNの脆弱性への対応を更新だけで終えるのではなく、現在使っている機能と外部へ公開している機能が一致しているかを見る、という読み替えはできます。

異常に気づくのは誰か

もうひとつ、この事例で目を引くのはSektorCERTの動きです。第1波で攻撃活動に気づき、対応チームを立ち上げ、対象企業へ連絡したのは外部の監視組織でした。

IPAの資料も、緩和策として設定・構成・ログの監視と分析を挙げています。本来は発生しないはずのマシン間の通信や、攻撃を有利に進めるための権限昇格などを検知するための対策で、攻撃の初期段階で検知できれば、深刻化する前にインシデント対応を行うことが期待できるとしています。

ファームウェアの更新は、判明した脆弱性を塞ぐ対策です。ログの監視は、想定していない動きが起きたときに気づくための仕組みで、役割が違います。リモートアクセスのログ管理を「あとで調べるための記録」だけでなく、「気づくための材料」として見ておくと、この違いが分かりやすくなります。

資料はさらに、ゼロデイ脆弱性によって完全には保護できないケースがあり得るとしたうえで、組織内部のネットワークセグメントを分割しておくことで被害の拡大を困難にし、最小限に抑えるという考え方も挙げています。

自社の機器で確認できる2つの問い

この事例から持ち帰れるのは、次の2つに絞られます。

  • いま使っていない機能が、インターネット側に開いたままになっていないか
  • 想定外の通信や挙動が起きたとき、誰がそれに気づくのか

修正プログラムを適用したかという確認に、この2つを足すと、点検の範囲がひとつ広がります。脱VPNの検討を進めている場合も、いま動いている機器で開いている口の数だけは、切り替えの前に把握しておく価値があります。

参考・出典