2010年に世界へ知られることになったStuxnetは、単に「非常に高度なコンピューターウイルス」だったのではない。最大の特徴は、Windows上で感染を広げた先に、SiemensのSTEP 7を使うエンジニアリング環境とPLCを見つけ、条件が一致した制御システムへ別のコードを送り込み、最終的には現実の設備の動作へ干渉するところまで設計されていたことにある。
この違いは大きい。一般的な情報システムへの攻撃では、盗まれるものは認証情報やファイル、停止するものはサーバーや業務アプリケーションである。Stuxnetでは、コンピューター上の処理がPLCの制御ロジックへつながり、そのPLCが周波数変換器やバルブなどの設備を動かす。攻撃の終点が「データ」ではなく「物理プロセス」だった。
そのためStuxnetを理解するときは、マルウェアの機能を一列に並べるだけでは不十分である。見るべきなのは、Windows、エンジニアリングステーション、STEP 7、PLC、フィールドネットワーク、ドライブ、そして遠心分離機という異なる層が、どのようにつながっていたかである。本CASEでは、この鎖を一段ずつ追っていく。
結論から言えば、Stuxnetは「ITからOTへ渡る攻撃」だった
Stuxnetの本質を最短で表すなら、IT環境への侵入を入口にして、OTの制御ロジックと物理プロセスを最終標的にしたマルウェアである。
ここでいうITは、Windows PC、ファイル共有、USBメモリ、ネットワーク通信など、一般的なコンピューター環境を指す。OT、Operational Technologyは、設備や工程を監視・制御する技術領域であり、PLC、DCS、SCADA、産業用ネットワーク、エンジニアリングステーションなどが含まれる。NISTの現在の定義でも、OTは物理環境と相互作用し、装置・プロセス・イベントを監視または制御するプログラマブルなシステムとして整理されている。
Stuxnetはこの境界をまたいだ。Windows側で生存・拡散し、目的のソフトウェアと装置構成を探し、条件が合ったときだけPLC側へ制御用コードを送り込む。逆に言えば、感染したWindows PCすべてが同じ物理被害を受けるわけではなかった。大半の感染先は、最終標的へ到達するための経路や足場だった。
この「選別」が、Stuxnetを単純なワームと分ける第一の特徴である。
発見されたのは2010年だが、活動はそれ以前に始まっていた
公開史では、Stuxnetは2010年6月、ベラルーシのセキュリティ企業VirusBlokAdaが異常なWindows障害を調べる過程で公に知られるようになった。その後、Microsoft、Symantecをはじめとする各社、ICS-CERTなどが解析を進めた。
しかし、解析によって集められた検体には、2010年6月より前の活動を示す情報が残っていた。SymantecのW32.Stuxnet Dossierでは、2009年の時点ですでに存在していた系統が確認され、2010年には複数の感染波があったと整理されている。後にさらに古いStuxnet 0.5系統が解析され、攻撃設計が一度きりの完成品ではなく、時間をかけて改変・運用されていたことも見えてきた。
したがって「2010年のStuxnet」という表現は、主に世界が発見し、解析し始めた年を示す。攻撃プログラム自体の開発や実運用は、それ以前へ遡る。
なぜ最初から異常なマルウェアだと分かったのか
Stuxnetが注目された理由の一つは、Windows上での侵入・拡散に投入された資源が多かったことである。
Microsoftが2010年8月に修正したMS10-046、CVE-2010-2568では、Windows Shellがショートカットのアイコンを扱う処理に問題があり、細工されたショートカットのアイコンを表示するだけでコードが実行され得た。[2]USBリムーバブルメディアは重要な攻撃経路の一つで、AutoPlayを単に無効にすれば完全に防げる性質ではなかった。
さらに、解析では複数の未修正脆弱性、盗用されたデジタル証明書による署名、ネットワーク内での複数の拡散手段、コマンド＆コントロールやピア間通信などが確認された。ICS-CERTは2010年度の年次レビューで、Stuxnetをゼロデイ、正規のデジタル署名、回避技術を組み合わせた高度なマルウェアとして扱い、制御システム分野にとって「security through obscurity」が成立しないことを示した出来事と位置づけた。
ここで重要なのは、「高度だったから被害が出た」とだけ理解しないことである。ゼロデイは侵入や拡散を助ける手段だったが、最終目的ではない。Stuxnetの価値は、Windowsに入った後のOT側ロジックまで含めて一つの作戦として設計されていた点にある。
一般のWindows PCを壊すことが目的ではなかった
ランサムウェアならファイルを暗号化し、ワイパーならデータを破壊する。ボットネットなら感染端末そのものを遠隔操作資源として利用する。Stuxnetは、それらとは異なる行動を取った。
StuxnetはSiemensのSTEP 7環境を探し、PLCとの通信経路へ介入する機能を持っていた。Broadcom/Symantecの解析では、STEP 7がPLCへアクセスするために使用するDLLを置き換え、正規DLLを別名で保持しながら、PLCのコードブロックの読み書きや探索に関係する一部の呼び出しを横取りする仕組みが示されている。
これは非常に重要な設計である。
エンジニアがSTEP 7からPLCを見れば、通常は「PC上のソフトウェアがPLCの実体を読み書きしている」と考える。しかし、その通信の途中にStuxnetが入り込むと、エンジニアリングステーションから見える情報と、PLCの内部で実際に動いている状態が一致しない可能性が生まれる。
攻撃者はPLCだけを改変するのではなく、PLCを確認するための道具まで同時に信用できなくする。ここが、後に「PLC rootkit」と表現された機能の本質である。
PLCが最終目的でもない
もう一段進めると、PLCさえ最終目的ではない。
PLCは現場の入力を読み、プログラムを実行し、出力を決定する。PLCが周波数変換器へ速度指令を送り、その周波数変換器がモーターを駆動し、モーターが遠心分離機を回すなら、PLCのロジック変更は現実の回転機械へ到達する。
Stuxnetの後期1.x系統についてSymantecが解析した攻撃では、特定のPLC構成と、特定メーカーの周波数変換器が存在し、さらにドライブが特定の高い周波数帯で運転されるという条件が確認された。条件が成立した環境では、通常運転を長く続けた後、短時間だけ出力周波数を1410 Hzへ上げ、別の局面では2 Hzへ落とし、さらに1064 Hzへ変えるといった操作が含まれていた。
ここで数値だけを見て「1410 Hzが危険だから攻撃だった」と単純化してはいけない。重要なのは、正常な運転パターンへ紛れながら、回転機械に意図しない速度変化や機械的ストレスを与える制御を、長期にわたり断続的に挿入するという設計である。
ソフトウェアが物理設備へ影響するためには、設備の種類、駆動方式、正常運転範囲、PLCプログラム構造を理解しなければならない。ここにはITセキュリティだけでなく、制御工学、プロセス工学、対象設備の運転知識が必要になる。
Stuxnetには一つの「攻撃ロジック」しかなかったわけではない
Stuxnetを説明するとき、よく知られた「遠心分離機の回転数を変えたマルウェア」という一文だけで済ませると、実際の構造を見失う。
2013年にSymantecが詳しく公表したStuxnet 0.5では、後期1.x系統で知られるS7-315系PLCと周波数変換器への操作とは異なり、S7-417系PLCを使う別の攻撃系統が解析された。[6]こちらでは、ウラン濃縮工程でUF6を扱うバルブ状態を操作し、通常時のプロセス値を記録して攻撃中に正常値を再生する機構が含まれていた。
つまり、Stuxnetという名前の下には、少なくとも時期と標的ロジックの異なる系統が存在する。
この点は後続記事でも重要になる。1.x系統で確認された「周波数変換器への速度操作」と、0.5系統で確認された「417 PLC・バルブ操作・正常値のreplay」は、同じ攻撃の一工程として無造作に混ぜてはいけない。どちらもNatanzとの強い整合性を持つが、技術的には区別して読む必要がある。
なぜNatanzが標的だと考えられたのか
Stuxnetが公表された直後からイランの核施設が標的ではないかという推測は広がったが、後の解析では、単なる地政学的な連想以上の技術的根拠が積み上がった。
一つは感染分布である。Symantecが感染履歴を解析すると、初期感染の起点とみられる組織がイランと結びつき、感染報告もイランに大きく偏っていた。
もう一つは、PLC側の標的条件である。StuxnetはPLCなら何でも攻撃するわけではなく、CPU型式、通信モジュール、PROFIBUS上の機器構成、周波数変換器のメーカーや運転条件などを確認していた。
さらにStuxnet 0.5の417系攻撃では、カスケードと呼ばれる遠心分離機群の構成を識別するための詳細なfingerprintが解析された。IAEAのNatanz Fuel Enrichment Plantに関する公開報告では、実際に164台のIR-1遠心分離機で1カスケードを構成し、複数のユニットに18カスケード単位の構成が存在していたことが確認できる。
マルウェア側の「期待する設備構成」と、公的資料側の「実在した設備構成」が、複数の点で重なったのである。
ただし、この一致から直ちに「誰が作ったか」まで確定するわけではない。標的推定と国家帰属は別問題であり、CASE061-07ではそのEvidenceの階層を分けて扱う。
被害規模は単純な一つの数字で固定できない
Stuxnetには「約1000台の遠心分離機を破壊した」という説明が広く知られている。しかし、公開情報から確実に言える範囲には限界がある。
IAEAはNatanzに設置・運転されていた遠心分離機の数を継続的に報告しており、時期によって稼働台数や設置台数が変化している。外部研究者や報道は、交換台数、設備停止、イラン側の運転データなどをStuxnetの活動時期と照合して影響を推定してきた。一方で、個々の遠心分離機の故障原因を外部から一台ずつ確認したわけではない。
したがって本CASEでは、物理影響があったこと自体と、その正確な台数・期間を分ける。Stuxnetが物理工程を操作する目的のコードを持ち、Natanzの設備構成と強く整合していたことは技術解析でかなり明確である。しかし「何台を、どの時点で、Stuxnetだけが壊したか」という数量評価には推定が含まれる。
技術史を扱うとき、印象的な一つの数字より、どこまでが直接証拠でどこからが推定かを残す方が重要である。
2010年が転換点になった理由
ICS-CERTは2010年を「Stuxnetの年」と表現した。これは誇張ではない。
Stuxnet以前にも産業システムへのサイバー脅威は存在した。しかしStuxnetは、攻撃者が一般的なWindows侵入技術だけでなく、PLCプログラム、産業用通信、特定工程の動作まで理解し、長期運用を前提にした専用攻撃を構築できることを、現実のコードとして示した。
制御システム側では、それまで「工場ネットワークはインターネットから隔離されている」「PLCは一般PCとは違う」「専用プロトコルや専用ソフトを使っているから外部の攻撃者には分からない」といった前提が安全性の一部として期待されることがあった。
Stuxnetはその前提を崩した。
隔離されたネットワークにも、保守用PC、USBメモリ、ノートPC、プロジェクトファイル、ベンダー作業、バックアップ媒体といった物理・運用上の接点がある。PLCはインターネットへ直接接続されていなくても、エンジニアリングステーションから新しいプログラムを受け取る。攻撃者がその正規の保守経路へ侵入すれば、air gapそのものを正面から「突破」する必要はない。
現代のMITRE ATT&CK for ICSでも、StuxnetはManipulation of Control、Manipulation of View、Modify Controller Taskingなど複数の技法の代表例として整理されている。つまり事件から十数年が経っても、Stuxnetの構造はOT攻撃を理解する基準点として残っている。
制御エンジニアの視点で見ると、何が最も異常だったのか
制御設計の立場からStuxnetを見ると、異常なのは「PLCを書き換えたこと」だけではない。
通常の設備改造では、要求仕様を定め、PLCプログラムを変更し、I/Oとインターロックを確認し、試運転し、異常系を検証し、変更履歴を残す。安全に関係する変更ほど、人間が意図的に追跡できる形で管理される。
Stuxnetはこの流れを逆向きに利用した。
正規のエンジニアリングソフトを通る通信へ割り込み、対象設備の構成が一致するまで待ち、制御ロジックへ追加コードを入れ、さらにエンジニアが読出し確認を行う経路まで偽装する。攻撃は「PLCの外」だけでなく「PLCを保守する仕組み」へ入り込んでいた。
設備側から見れば、指令値が変化しているのに監視側では正常に見える状況が生じ得る。これは単純な通信断やCPU停止より厄介である。停止なら異常として扱えるが、誤った制御が継続しながら正常表示が残れば、原因切り分けそのものが遅れる。
この構造は、現在のOTセキュリティでも重要な論点である。セキュリティ対策を「Windows PCへアンチウイルスを入れる」だけに縮めると、PLCロジックの完全性、Engineering Workstationの信頼性、変更管理、プロセス値の独立検証が抜け落ちる。
このCASEで追う8つの問い
ここからの7記事では、Stuxnetを一つの巨大な「サイバー兵器」という言葉で済ませず、機能を層ごとに分解する。
次のCASE061-02では、インターネットから隔離された制御網へ、USB、Windowsの脆弱性、ネットワーク内拡散、STEP 7プロジェクトなどを使ってどう近づいたのかを見る。
CASE061-03では、感染先のすべてを破壊せず、なぜSiemensの特定構成だけを探せたのかを、S7-300/S7-400、CP342-5、PROFIBUS、接続機器の識別から読む。[4]
CASE061-04では、PLCへコードを送り込むだけでなく、STEP 7側からの読出しをどう隠し、さらに0.5系統ではプロセス値のreplayによって監視を欺いたのかを整理する。
CASE061-05では、周波数変換器への指令がどのように回転機械へ物理的ストレスを与えるのかを、制御工学の観点から見る。
CASE061-06では、マルウェアのfingerprintとIAEAが公開していたNatanzの設備構成を照合し、「Natanzが標的だった」という判断がどのEvidenceから組み上がったのかを確認する。
CASE061-07では、米国とイスラエルが関与したとする主要報道と、技術解析で確認できる事実を分離する。作戦名「Olympic Games」を含む説明は広く定着しているが、匿名政府関係者への取材を核とする報道と、公的な国家承認は同じではない。
最後のCASE061-08では、事件を過去の特殊事例として終わらせず、現在の工場・インフラで何を防御設計へ落とし込むべきかを考える。
検証ポイント｜「Stuxnet＝USBウイルス」ではない
StuxnetをUSBウイルスと呼ぶ説明は、入口の一部だけを切り取っている。
USBは重要な感染経路だった。CVE-2010-2568は、悪意あるショートカットのアイコン表示を通じてコードが動作し得るため、ユーザーが実行ファイルをダブルクリックする典型的な感染像とは異なっていた。しかしStuxnetにはネットワーク内での複数の拡散手段があり、STEP 7プロジェクトを介する経路もあった。
そして何より、USBは「最終攻撃」ではない。USBからWindowsへ入り、Windowsからエンジニアリング環境へ進み、PLCへ到達し、そのPLCが物理設備を制御する。攻撃チェーンの入口と終点を混同しないことが重要である。
検証ポイント｜「air gapなら安全」だったわけでもない
Natanzのような高い隔離性が期待される施設が狙われたことから、「Stuxnetはair gapを破った」と表現されることがある。
しかしair gapは、物理的に何の情報も出入りしない真空状態を意味しない。実際の設備には、保守、設定変更、ログ回収、ベンダーサポート、ソフト更新、バックアップなどの運用がある。Engineering Workstationは、PLCへプログラムや設定を転送するために存在する。リムーバブルメディアや持込みPCが使われれば、論理的に隔離されたネットワークにも情報の経路が生まれる。
MITRE ATT&CK for ICSでもEngineering Workstationは、保守・設定・診断に用いられ、セグメント化またはair-gappedなネットワークでもファイル転送や装置接続の要所になり得る資産として扱われる。
Stuxnetが突いたのは「air gapという技術そのものの欠陥」だけではなく、隔離設備にも必ず存在する保守運用の接点だった、と考える方が正確である。
検証ポイント｜「Stuxnetがサイバー攻撃を発明した」わけではない
Stuxnet以前にもコンピューター攻撃は存在し、制御システムに影響する事例もあった。したがってStuxnetを「世界初のサイバー攻撃」と呼ぶのは不正確である。
一方で、公開解析されたマルウェアとして、特定のPLCと物理プロセスを狙う専用ロジックを持ち、制御と監視の双方を操作して設備損傷を目指した例として、Stuxnetが歴史的な転換点であることは間違いない。
その意味で重要なのは「初めてインターネットで攻撃した」ことではない。コードが現実の機械を操作するための設計図になったことである。
まとめ
Stuxnetは、Windowsマルウェア、PLC攻撃、核施設への破壊工作という三つの話を別々に持っていたのではない。それらを一つの制御チェーンとして接続していた。
Windows側では侵入と拡散を行う。Engineering StationではSTEP 7とPLCの通信へ割り込む。PLC側では対象構成を識別し、条件が合ったときだけ攻撃ロジックを実行する。さらに物理プロセスでは、周波数変換器やバルブを通じて実設備の状態を変える。そして一部の系統では、監視側に正常値を見せて異常そのものを隠す。
だからStuxnetは、単なる「強いウイルス」ではない。
それは、IT、OT、制御ロジック、物理設備、運用者の監視という複数の層を一体として設計したサイバー物理攻撃だった。
次の記事では、その最初の難関だった「隔離された制御網へどう到達したのか」を追う。USBだけでなく、Windowsのゼロデイ、ネットワーク内拡散、STEP 7という保守経路まで含めて、入口側の構造を分解する。
FACT CHECK｜出典・参考資料
- [1] U.S. Department of Homeland Security / ICS-CERT, ICS-CERT – 2010 Year in Review
- [2] Microsoft, Security Bulletin MS10-046: Vulnerability in Windows Shell Could Allow Remote Code Execution (CVE-2010-2568)
- [3] Nicolas Falliere, Liam O Murchu, Eric Chien, Symantec, W32.Stuxnet Dossier , Version 1.4, 2011
- [4] Symantec/Broadcom, Exploring Stuxnet’s PLC Infection Process
- [5] Symantec/Broadcom, Stuxnet: A Breakthrough
- [6] Symantec/Broadcom, Stuxnet 0.5: Disrupting Uranium Processing at Natanz
- [7] IAEA, Implementation of the NPT Safeguards Agreement and relevant provisions of Security Council resolutions in the Islamic Republic of Iran , GOV/2010/46
- [8] MITRE ATT&CK for ICS, Stuxnet, Software S0603
- [9] NIST, SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
Stuxnet｜核施設を狙ったサイバー攻撃は何だったのか 第1回 全8回 全8回を見る
- 01 Stuxnetとは何だったのか――コンピューターから現実の設備へ
- 02 Stuxnet｜隔離された制御網へどう入ったのか――USBとゼロデイの侵入経路
- 03 Stuxnet｜なぜSiemensの制御システムだけを探したのか――STEP 7とPLCの識別
- 04 Stuxnet｜PLCを書き換えてもなぜ気づかれなかったのか――制御ロジック改変と偽装
- 05 Stuxnet｜遠心分離機はどう攻撃されたのか――周波数変換器と回転数操作
- 06 Stuxnet｜なぜ標的はナタンズだと分かったのか――コードと設備構成の照合
- 07 Stuxnetを誰が作ったのか――帰属で「分かっていること」と「分からないこと」
- 08 Stuxnetが変えたもの――産業制御セキュリティに残った教訓