Stuxnet｜なぜSiemensの制御システムだけを探したのか――STEP 7とPLCの識別

Stuxnetが異例だった理由は、Windowsへ侵入した後に「何かを壊す」のではなく、まず制御システムの構成を調べたことにある。

感染したPCがSiemens STEP 7を使うEngineering Workstationなのか。そこから到達できるPLCはどのCPUなのか。PROFIBUS通信を行うモジュールがあるのか。その先にどの種類の機器がぶら下がっているのか。さらに一部の攻撃では、周波数変換器のメーカーや運転周波数まで条件に含まれていた。

これは一般的なPCマルウェアの「OSの種類が合えば攻撃する」という選別とは桁が違う。Stuxnetは、設備の制御アーキテクチャそのものをfingerprintしていた。

この仕組みを理解すると、なぜ世界中のWindows PCへ感染が広がっても、同じ物理攻撃が世界中で起きなかったのかが分かる。Windows側の感染範囲と、OT側の攻撃対象は別の条件で絞り込まれていたからである。

結論――Stuxnetは「Siemens製なら何でも」攻撃したわけではない

StuxnetはSiemens製品を狙った、とよく要約される。しかし技術的には、それでもまだ粗い。

狙われたのは、SiemensのSTEP 7を使ってプログラムされる特定のS7 PLCと、その周囲にある通信・フィールド機器が、攻撃コード側の期待する構成へ一致した場合である。

Symantec/Broadcomの解析では、後期の1.x系統でS7-315系のPLCとPROFIBUS通信、CP342-5などの構成が重要な条件になっていた。別のStuxnet 0.5ではS7-417系PLCを対象にし、さらに設備内のカスケード構成を識別する別のfingerprintが存在した。

したがって、Stuxnetのtargetingは一段ではない。

1. Windows上でSTEP 7環境を見つける。
2. PLCとの通信へ介入できる位置を取る。
3. PLCのCPUや構成データを調べる。
4. PROFIBUS上の機器や設備構成を調べる。
5. 条件が一致した場合にだけ、対応するPLCペイロードを動かす。

この多段選別が、Stuxnetを「目的設備を探すマルウェア」にしていた。

STEP 7は何をするソフトウェアなのか

Siemens STEP 7は、SIMATIC S7シリーズのPLCを設定・プログラミング・診断するためのエンジニアリングソフトウェアである。

制御エンジニアはSTEP 7上でハードウェア構成を定義し、PLCプログラムを作り、オンライン接続してCPUへダウンロードする。稼働中のPLCからプログラムやデータを読み出し、監視し、故障診断することもある。

つまりSTEP 7を実行するPCは、単なる監視端末ではない。

PLCの中身を書き換える正規の権限を持つ保守端末である。

Stuxnetはここへ到達すると、STEP 7とPLCの間で使われるソフトウェア部品へ介入した。Broadcom/Symantecの解析では、PLCアクセスを処理するs7otbxdx.dllに相当する正規DLLを別名へ退避し、自身のDLLで置き換える方式が確認された。置換されたDLLは正規の機能を多く引き継ぎながら、PLCのコードブロックの読出し、書込み、探索に関係する一部の呼出しだけを横取りした。

これにより、エンジニアから見ればSTEP 7は普段どおり動く一方、Stuxnetは裏でPLCとのやり取りを観察・変更できる。

この構造が、標的識別の入口になる。

CPU型式を確認する意味

PLCは同じメーカーでも、CPU型式によって能力、メモリ構成、通信、プログラム構造が異なる。

攻撃コードをPLCへ送り込むなら、対象CPUに合わせたロジックが必要になる。一般のWindowsプログラムのように「x86ならだいたい同じ」とは扱えない。

Stuxnetの解析では、S7-315系とS7-417系という異なるCPUファミリが、異なる攻撃系統で重要になった。

後期1.x系統でよく知られる周波数変換器への攻撃では、S7-315系PLCと特定の通信構成が関係していた。Stuxnet 0.5で詳しく解析された別系統では、417 PLCでなければ攻撃用処理を進めない条件があった。

ここから分かるのは、攻撃者がPLCを単なる「小型コンピューター」として扱っていなかったことだ。

対象設備の制御プログラムが、どのCPUで、どの通信モジュールを使い、どのI/O・フィールド機器を制御するかを前提にコードが作られていた。

制御設計で機種変更をするとき、同じラダーやSTをそのまま移せるとは限らない。ユニット構成、アドレス、通信設定、特殊機能、スキャンタイミングなどを確認する。Stuxnetの攻撃ロジックも、それと同じように「対象ハードウェアの前提条件」を持っていたと考えると理解しやすい。

CP342-5とPROFIBUSがなぜ重要なのか

S7-300シリーズでは、CP342-5のような通信プロセッサを使ってPROFIBUSネットワークへ接続する構成がある。

PROFIBUSは産業用フィールドバスで、PLCからインバータ、リモートI/O、各種フィールド機器へ指令・データをやり取りするために広く使われてきた。

Stuxnetにとって、この構成情報は「このPLCの先に何がいるか」を判断する手掛かりになる。

Symantecの解析では、対象PLCのSystem Data Blocks、SDBなどに含まれる構成情報を読み、PROFIBUS接続の状況や特定のモジュールを調べる処理が確認された。攻撃コードは、PLCが存在するだけで即座に物理操作を始めるのではなく、フィールドネットワークの構造が期待どおりかを確認していた。

ここは制御エンジニアにとって非常に重要な点である。

PLCプログラムだけでなく、ハードウェア構成データそのものが設備のfingerprintになる。

どのCPUを使うか。どの通信モジュールを挿すか。PROFIBUSの局構成はどうなっているか。接続機器の識別情報は何か。こうした情報を組み合わせると、設備の用途や設計パターンをかなり狭く推定できる。

Stuxnetはその性質を利用した。

周波数変換器まで確認する理由

後期1.x系統の攻撃では、PLCの先に接続された周波数変換器が重要だった。

周波数変換器、VFDは、モーターへ与える周波数・電圧を制御して回転速度を調整する装置である。一般的な搬送設備やポンプ、ファンでも使われるが、Stuxnetの標的条件は「VFDがあればよい」という単純なものではなかった。

Symantecの解析では、特定メーカーのドライブを識別し、さらに通常運転時の出力周波数が特定の高い範囲にあることを確認する条件が報告された。

これは非常に強いフィルターである。

通常の工場では、モーターの運転周波数は50 Hzや60 Hz付近、あるいは数十Hz〜100Hz程度で使うことが多い。Stuxnetが注目した807〜1210 Hz級の領域は、一般的なコンベヤやポンプとは大きく異なる。

この条件を追加すれば、「Siemens PLC＋PROFIBUS＋VFD」というまだ広い候補から、かなり特殊な高速回転用途へ対象を絞ることができる。

攻撃コードは、設備名を文字列で「Natanz」と検索する必要がない。

設備を構成する部品と運転条件の組合せを見ればよい。

この考え方がStuxnetの標的 fingerprintの核心である。

設備のfingerprintとは何か

セキュリティ分野のfingerprintは、相手の特徴を組み合わせて識別することを意味する。

OTで考えるなら、次のような情報がfingerprintになり得る。

• PLCメーカーとCPU型式
• ラック・モジュール構成
• 通信モジュール
• フィールドネットワーク種別
• PROFIBUSアドレス
• 接続されているドライブやI/O
• ドライブメーカー
• パラメータや通常運転範囲
• PLC内のData Block構成
• シンボル名やプログラム構造
• 接続局数

一つ一つは一般的でも、組合せると特定設備へ近づく。

たとえば「三菱PLCを使っている」だけでは対象設備は特定できない。しかしCPU型式、位置決めユニット、サーボアンプ、Ethernet/IP機器、I/O構成、特定レシピデータの並びまで一致すれば、設備の種類はかなり絞れる。

Stuxnetでは、この考え方を攻撃側が自動化していた。

しかもfingerprintが一致しないときに破壊動作を始めないことで、標的外の設備で物理異常を起こす確率を下げていた。

Stuxnet 0.5ではさらに具体的な設備構成を見ていた

2013年に公開されたSymantec/BroadcomのStuxnet 0.5解析では、417 PLCを対象にした古い攻撃系統が詳しく示された。^[3]

この系統では、単にCPU型式を確認するだけではない。PLC側の構成データを読み、ウラン濃縮設備のカスケードと関連機器を識別するための情報を集めていた。

Symantecは、このfingerprintがNatanzの既知の設備構成と強く一致すると分析した。

とくに重要なのが、遠心分離機を複数台まとめたcascadeという単位である。IAEAの公開報告には、Natanzで164台のIR-1遠心分離機を一つのcascadeとして運転していたこと、さらにFuel Enrichment Plantのユニットで18 cascades単位の構成が存在したことが記録されている。^[3]

マルウェア内部の期待構成と、国際機関が公開していた実設備の構成が重なる。

この一致は「Stuxnetがイランで多く見つかった」という地理的な統計より一段強い。コードの中に設備の設計条件が埋め込まれていたからである。

ただし、このEvidenceの積み上げはCASE061-06で詳しく行う。本記事では、Stuxnetが標的を選ぶためにPLCとフィールド構成を読んでいた、という技術構造に焦点を置く。

0.5系統と1.x系統を混ぜない

Stuxnet解説で混乱しやすいのが、417系と315系の話である。

後期1.x系統では、S7-315系とPROFIBUS、周波数変換器を組み合わせた攻撃が広く知られている。そこでは出力周波数を1410 Hz、2 Hz、1064 Hzなどへ変える動作が解析された。

一方、Stuxnet 0.5ではS7-417系PLCを対象とし、バルブ操作とプロセス値の記録・replayを組み合わせる別の攻撃が確認された。^[3]

両方ともNatanzのウラン濃縮設備を狙ったと考えられるが、同じPLCに同じペイロードを入れたわけではない。

この区別は重要である。

「Stuxnetは417 PLCでVFDを1410 Hzにした」と書けば、異なる系統を混ぜることになる。逆に「315系攻撃でバルブを閉じ、正常値をreplayした」と断定するのも同じ問題がある。

本CASEでは、各系統のEvidenceを分けたまま扱う。

なぜ標的外では静かにしていたのか

選別機構の目的は、攻撃の精度を上げることだけではない。

不用意に標的外設備を壊せば、マルウェアの存在が早く露見する。一般工場でモーターが突然異常運転すれば、保全担当者は原因を調べる。PLCプログラムに見覚えのないブロックがあれば、ベンダーへ解析依頼が出る。異常が複数業界で同時発生すれば、攻撃コードの共通性が見つかりやすい。

標的条件が一致するまで攻撃しない設計なら、多くのWindows PCへ感染しても、目立つ物理症状を出さずに移動できる。

StuxnetのWindows感染が世界へ広がった一方、物理攻撃は特定環境へ集中したと考えられるのは、この二層構造による。

攻撃側から見れば、配送層は広く、破壊層は狭くするのが合理的だった。

正規の保守情報が攻撃側にも価値を持つ

設備設計では、ハードウェア構成を正しく管理することは保守性のために必要である。

CPU型式、通信モジュール、局番、ネットワーク構成、ドライブ型式、デバイス割付、パラメータ。これらが分からなければ故障復旧も改造もできない。

しかし同じ情報は、攻撃側が標的を識別する材料にもなる。

だからといって、設備情報をすべて隠せば安全になるわけではない。ICS-CERTがStuxnet後に強調したように、「security through obscurity」だけでは防御にならない。

重要なのは、構成情報の価値を認識したうえで、誰が読めるか、どこにコピーできるか、どのEngineering Workstationがオンラインアクセスできるかを管理することである。

さらに、PLC側で正規ロジックと実行ロジックの整合性を確認できれば、Engineering Workstationが侵害されても異常に気づく可能性が上がる。

Stuxnetは「PLCはネットワークの奥にあるから攻撃者には分からない」という前提を崩した。攻撃者はPLCの構成を読み、必要ならそこで標的判定を行える。

検証ポイント｜「S7-300を使っていたら危険だった」ではない

Stuxnetの対象にS7-300系が含まれたからといって、当時S7-300を使う全設備が物理攻撃の標的だったわけではない。

攻撃には追加条件があった。

CPU、通信モジュール、PROFIBUS上の機器、周波数変換器、運転周波数など複数の条件が組み合わされる。条件を外れたPLCでは、感染したEngineering Workstationが存在しても、同じ攻撃シーケンスは発動しない。

したがって「メーカー」「PLCシリーズ」だけで標的を説明するのは不正確である。

Stuxnetの重要性は、ベンダー名ではなく、設備構成を読み取って攻撃対象を選ぶロジックにある。

検証ポイント｜「PLCのパスワードを破った」ことが核心ではない

Stuxnetを一般的な不正ログインの延長として理解すると、本質がずれる。

公開解析で中心になるのは、Engineering Workstation上のSTEP 7通信経路へ介入し、正規ソフトウェアが持つPLCアクセス機能を利用する構造である。

つまり、攻撃者が外部からPLCへログイン画面を開き、パスワードを総当たりした、という話ではない。

信頼済みのEngineering Workstationが侵害され、その端末から行われる正規の制御変更と悪性変更の境界が崩れたことが重要だった。

現在のOT防御でも、この観点は残る。「PLCにパスワードを設定したか」だけでなく、「誰がPLCを書き換えられる端末を支配できるか」を見なければならない。

制御設計の視点で見る標的 fingerprint

制御システムの実務では、同じ装置名でも構成が少し違うだけでプログラムやパラメータは変わる。

ラインAとラインBでインバータ型式が違う。増設機ではPROFIBUSからPROFINETへ変わっている。CPU更新でデータブロック構造が変わる。安全回路やインターロックも設備世代ごとに違う。

攻撃コードが物理設備を確実に壊したいなら、こうした差を無視できない。

Stuxnetが行った構成判定は、裏返せば「攻撃者も設備エンジニアと同じようにBOMとI/Oとネットワーク構成を考える必要があった」ということだ。

この事実は、Stuxnetの開発に相当な事前情報と試験が必要だったことを示唆する。ただし、それだけで開発主体を特定することはできない。高度な設備知識が必要だったという技術的推論と、どの国家組織が実施したかという帰属判断は分離する必要がある。

fingerprintと「設備名の特定」は同じではない

Stuxnetの標的 fingerprintを説明するとき、「コードの中にNatanzの設計図が入っていた」と表現すると分かりやすいが、厳密には注意が必要である。公開解析で見えるのは、CPU型式、通信構成、接続機器、カスケード構造など、設備を特徴づける条件の集合である。

これは、住所や設備名称を直接検索する方法とは違う。

たとえばPLC内に「NATANZ」という文字列がなくても、164台単位の遠心分離機カスケード、特定の417系制御、関連するバルブや配管系統の構成が一致すれば、目的設備をかなり高い確率で識別できる。逆に、別施設が偶然まったく同じ構成を持っていれば、同じfingerprintへ一致する可能性は理論上残る。

だから技術解析から導ける表現は、「Natanzの既知構成と非常に強く一致する」であり、「コードが施設名を直接確認していた」ではない。CASE061-06では、この違いをIAEA資料と照合してさらに検証する。

この境界は帰属問題でも重要になる。fingerprintが特殊であるほど、攻撃者が標的設備に関する詳細な情報を事前に持っていた可能性は高まる。しかし、どの情報機関・企業・研究機関がその情報を提供したかまではコードだけでは証明できない。

防御側は「構成を知られている」前提へ変える必要がある

Stuxnet以前の制御システムには、専用装置や非公開に近い構成が一種の防壁になるという期待が残っていた。だが、Engineering Workstationへ侵入されれば、攻撃者は正規ソフトウェアと同じ経路から構成を読むことができる。

このため防御設計では、設備構成を秘密にすることより、構成を読まれても勝手に変更できないこと、変更されたら検出できることの方が重要になる。

実務的には、PLCプログラムの基準版を保存し、オンライン差分を定期確認する。Engineering Workstationの変更履歴を残す。PLCへのダウンロードを認可制にする。不要時には書込み経路を閉じる。制御ロジック、ハードウェア構成、ドライブパラメータのバックアップを個別に保持する。こうした施策は、標的fingerprintそのものを隠すより再現性が高い。

また、ネットワーク監視だけでなく、設備側のプロセス異常を独立に見る必要もある。PLCから報告される値だけを唯一の真実にすると、CASE061-04で扱うようなManipulation of Viewに弱い。速度、振動、電流、流量など、重要な物理量を別経路で検証できれば、制御ロジックが改変されても異常を検出できる余地が増える。

Stuxnetの標的 fingerprintは、攻撃者が設備を詳しく知らなければOTを攻撃できない、という安心材料ではない。むしろ、いったんEngineering Workstationへ入れば、設備自身が攻撃者へ構成情報を教える可能性があることを示した。

まとめ

StuxnetはSiemens製PLCを見つけたら無差別に攻撃するマルウェアではなかった。

STEP 7環境へ到達した後、PLCのCPU型式、通信モジュール、PROFIBUS構成、接続された周波数変換器、運転条件などを調べ、攻撃側の期待する設備だけを選んだ。Stuxnet 0.5ではさらに417 PLCとカスケード構成を識別し、Natanzの公開設備情報と強く整合するfingerprintが確認された。

これによって、Windows感染は広くても、物理攻撃は狭くできた。

Stuxnetの精密さは、破壊コードそのものより、その前にある「この設備は本当に目的の設備か」という判定ロジックにも表れている。

次の記事では、その標的へ到達した後の問題へ進む。PLCへ悪性コードを書き込むだけなら、エンジニアがSTEP 7からオンライン確認すれば見つかる可能性がある。Stuxnetはなぜ、それでも長期間気づかれにくくできたのか。次の焦点は制御ロジックの改変と、その改変を見えなくする仕組みである。