Siemens Software Centerの悪用を確認！署名付きファイルの隣に潜むDLLを点検

Siemensは2026年10月19日、Siemens Software Centerの脆弱性CVE-2026-110936が実際に悪用されていると発表しました。攻撃で利用されたのは、有効な署名を持つ正規の実行ファイルと、攻撃者が用意したDLLの組み合わせです。実行ファイルそのものの署名が正しくても、起動時に読み込む別ファイルまで安全と判断できない点が重要です。

このニュースは、Webサーバーへ直接送る攻撃の話ではありません。しかし、サイトを更新するWindows端末には、管理画面へのセッション、リポジトリや配信先への接続情報が置かれていることがあります。制作や運用に使う端末を調べる対象として、担当部署へ共有したい情報です。

脆弱性の初回公表日は10月15日、勧告の最終更新と悪用確認の発表日は10月19日です。本記事の情報確認日は日本時間10月20日で、攻撃の開始日を示すものではありません。以下では公表内容と、本サイトが提案するWeb運用者向けの確認手順を分けて説明します。

更新対象と公表日を先に押さえる

Siemensの勧告SSA-580366によると、影響するのはSiemens Software Centerの4.0.9.8未満で、4.0.9.8以降への更新が案内されています。CVSSは版により異なり、v3.1は6.7、v4.0は8.4です。数字だけを引用する場合も、どちらの版かを明記する必要があります。

勧告は、制御されていない検索場所からDLLを読み込むことで、認証済みのローカル攻撃者が細工したDLLを置き、アプリケーションの権限でコードを実行できる問題と説明しています。インターネットから無条件に侵入できるサーバーの脆弱性へ読み替えてはいけません。

Siemens：セキュリティ勧告 SSA-580366

正規の実行ファイルと攻撃者のDLLが組み合わされた

Siemensの発表では、正規のプログラムは改変されず、攻撃者が隣に置いたDLLへ悪意あるコードが入っていました。同社は、把握している限りSiemensのシステム、製品、更新経路が侵害されたわけではないと説明しています。

したがって、「Siemensの更新を受け取った利用者全員へ不正ファイルが届いた」とは言えません。また、確認した一次資料はこの攻撃をAIによる攻撃と認定していないため、本記事でもAI悪用とは扱いません。正規ファイルを利用する実行経路と、不正な配布物を区別して調べる必要があります。

Siemens ProductCERT：悪用確認と検知・対応情報（2026年10月19日）

署名の確認だけでは実行される内容を説明できない

DLLはアプリケーションが機能を利用するために読み込むライブラリーです。Microsoftの資料は、読み込み時に完全なパスを指定しない場合などに検索が行われ、その順序にはアプリの種類や設定などが関わることを説明しています。「どの場所から読み込むか」が実行結果に影響します。

Microsoft Learn：DLLの検索順序

サイト運営の端末でなぜ確認が必要か

ここからは本サイトの運用上の提案です。例えば、制作担当者が資料の確認や別の業務で使う端末から、CMSやクラウドの管理画面にもログインしている状況を考えます。その端末で不正なコードが動けば、サイト側の脆弱性を使わずに、端末が持つ情報へ影響する可能性があります。

ただし、今回の公表だけで、自社のサイト情報やブラウザーのデータが盗まれたと判断することはできません。どの端末で、どのユーザー権限で、何が実行されたかを調べて影響範囲を決めます。脆弱なソフトがあること、悪用されたこと、情報が流出したことはそれぞれ別の確認事項です。

Web担当だけで利用ソフトを把握しきれない場合は、情報システム部門や委託先へ確認を依頼します。サーバー管理の一覧に載っていないから対象外とせず、制作・保守・問い合わせ対応に使う端末まで範囲を明確にしましょう。

最初に利用状況と実行場所を調べる

本サイトでは、端末ごとに製品の利用有無、インストール先、現在のバージョン、最後に起動した時期、管理者を記録することを提案します。ソフトウェアの一覧だけでなく、通常とは違う場所に同名の実行ファイルがないかも、管理手順に従って調べます。

ファイル名だけで不正と判定してはいけません。一方で、見慣れた名前や署名があることだけを理由に調査を終えることも避けます。実行ファイルを誰が入手し、どのフォルダーへ配置し、隣に何が置かれていたかという経路を確認します。

利用していないはずの端末で見つかった場合は、その場で起動して確認する方法を取らず、担当者へ引き継ぎます。調査のために不審なファイルを実行すると、状態を変えたり新たな処理を動かしたりするおそれがあります。通常の正規インストールと、不審なコピーを区別することが先です。

更新と侵害調査は別の完了条件を持つ

Siemensは、既存のインストールは次の起動時に自動更新されると案内しています。ただし運用上は、自動更新の設定を見ただけで終了せず、正規のインストールの版が実際に更新されたことを確認します。不審なコピーを見つけた場合は、単純に起動して更新させる対応とは分けて扱ってください。

本サイトの提案として、更新作業では対象端末数、更新後の版、確認者、確認時刻を記録します。起動していない端末や長期持ち出し端末が残っていないかも確認します。更新できないものは未完了として管理し、使用の継続条件を担当部門と決めます。

版を更新できても、更新前に不正なコードが動いていたかは別の問題です。侵害の兆候がある端末では、更新だけで解決したと判断せず、実行履歴や通信、残されたファイルなどの調査へ進めます。脆弱性の解消と、被害の有無の確認を同じチェック欄にしないことが重要です。

公表された兆候は公式情報と照合する

Siemensの発表は、想定外の起動登録、特定のフォルダーや同梱ファイル、不審な起動元などの確認事項と、通信先の指標を掲載しています。実際に照合するときは、公式ページの値と説明を直接参照してください。指標の状態は発表時点のもので、その後も同じとは限りません。

本サイトでは、ファイルの一致だけでなく、保存場所、実行の親子関係、発生時刻、関連する通信を組み合わせて判断することを提案します。一つの名前が見つかったことだけで感染を確定せず、見つからなかったことだけで無被害とも判断しません。

調査ログの保存期間が短ければ、過去の状況が分からない場合があります。確認できた事実と、記録がなく判断できない部分を報告へ分けて記載します。侵害が疑われる場合の端末隔離や証拠保全は、組織のインシデント対応手順に従って進めてください。

管理用の認証情報への影響を整理する

サイト運営者としては、疑わしい端末で利用していたCMS、ホスティング、Git、DNS、クラウドなどへの接続状況を確認することを提案します。今回の事例でそれらが盗まれたという意味ではなく、調査対象を決めるための棚卸しです。

失効や変更が必要と判断された場合は、疑わしい端末から作業を続けず、管理された別の環境を使います。パスワードだけを変更して終わらず、ログイン済みセッションやAPIキーなど、利用していた認証手段に応じた対応を担当者と確認します。

一律にすべての接続を止めると、更新や連絡にも影響します。影響の大きい管理権限を先に確認し、サービスの継続と調査の両方を考えて対応範囲を決めます。実施した失効と、まだ有効な接続を記録すると引き継ぎやすくなります。

開発側はDLLの読み込み先もレビューする

MicrosoftのDLLセキュリティ資料は、攻撃者が制御できる場所からの読み込みを避けるための対策を説明しています。Windows用の補助ツールやインストーラーを自作している場合、DLLの検索場所や読み込み方法もレビュー対象になります。

Microsoft Learn：DLLのセキュリティ

対策を実装しただけでなく条件を変えて検証する

本サイトでは、開発者がDLLの探索を見直す際に、アプリの配置先、作業ディレクトリー、依存するDLL、実行ユーザーが変わったときの挙動を確認することを提案します。自社アプリに合うAPIや設定はMicrosoftの資料と製品の要件を確認し、第三者のソフトへ根拠なく設定を適用しないでください。

通常の操作で起動できるかに加え、意図した場所から依存ファイルが読み込まれるか、別の場所の同名ファイルが使われないかを、隔離した検証環境で調べます。本番端末へ不審なDLLを置いて再現を試す必要はありません。

署名や許可リスト、EDRなどの仕組みも、対象とするファイルや挙動によって防げる範囲が変わります。今回のように正規ファイルが組み合わされる場合には、実行ファイルの名前だけで許可する運用が十分かを、担当者と確認しましょう。

委託先へ依頼するときは確認範囲を明示する

保守を委託しているサイトでは、「脆弱性対応済みです」という回答が、サーバーの更新だけを意味している場合があります。本サイトからは、今回は作業端末の製品利用状況と版の確認なのか、不正実行の調査まで含むのかを依頼文に明記することを提案します。

確認できた端末の範囲と例外を共有してもらうと、担当外の端末を対象に含めたつもりになる行き違いを減らせます。端末の詳細ログや秘密情報をメールへ無制限に添付させず、共有する情報と安全な受け渡し方法も合わせて決めてください。

対応の終了時に残す確認事項

今回まず共有したい事実は、悪用確認が公表されていること、対象製品に更新があること、正規の署名があるファイルと不正なDLLが組み合わされたことです。攻撃が始まった日時や自社の被害まで、公表内容から推測してはいけません。

運用では、利用端末の棚卸し、正規インストールの更新確認、不審なコピーや実行経路の調査、必要に応じた認証情報への対応をそれぞれ記録します。未確認の端末やログ不足の項目は、対応済みへ含めず残します。

サイトの防御はWebアプリケーションの更新だけで完結しません。制作や保守を行う端末がどの権限を持つかを把握し、正規ソフトの名前や署名を見た後も実行の組み合わせを確かめることが、今回の発表から取れる実務上の行動です。