使用 Siemens Software Center 的團隊，應確認版本已到 4.0.9.8 或更新版本；若端點出現來源不明的同名程式，交給事件應變流程調查，別為了觸發更新直接打開它。這次攻擊用的 EXE 本身可以有合法簽章，問題出在它啟動後載入了誰放在旁邊的 DLL。

Siemens 10 月 19 日公告確認 CVE-2026-110936 已遭實際利用。Romulus ClickFix 活動將未修改、有效簽章的 3.5.8.7 版程式與惡意 DLL 綑綁，在官方通路以外散布。官方目前所知沒有 Siemens 系統、產品或更新通道遭入侵，不能把這件事寫成官方更新被植入惡意程式。

本文查核截至臺北時間 2026 年 10 月 20 日。以下排查與測試是工程建議，未執行惡意樣本，也未在 Windows 主機重現漏洞。

更新已安裝版本，與調查可疑副本，是兩件工作

SSA-580366 V1.2列出的受影響範圍是所有低於 4.0.9.8 的版本。公告首次發布於 10 月 15 日，10 月 19 日補上實際利用說明；本次新進展是確認遭利用，並非漏洞今天才公布。已安裝版本會在下次啟動時自動更新，但這不能證明另一個目錄裡的副本也已更新，更不能清除先前載入過的惡意程式。

例如資產清單顯示公司核准的安裝已升級，EDR 卻看到同名 EXE 從使用者目錄啟動。這是本文假設的排查情境：兩份檔案可以同名，版本、路徑與來源卻不同。若值班同事只回報「Siemens 已更新」，下一班很容易把第二份副本漏掉。

因此，更新工單至少要留下實際檔案路徑、版本與確認時間；可疑執行紀錄則另列主機、使用者、父程序、載入模組與時間範圍。資料從組織已授權的端點工具取得，不需要在可疑主機上重新執行程式來「確認看看」。

Siemens 提供的一個調查線索，是由 msiexec 啟動、從 AppData\Local\Programs 執行的 SiemensSoftwareCenter.exe。這是值得追查的組合，不代表任何單一目錄或程序名稱都能獨立證明入侵。完整 IOC 與處置順序請核對官方原文。

CVSS 的 UI:N，不會把整場攻擊變成遠端零互動

這個漏洞的直接條件，是已驗證的本地攻擊者把 DLL 放進程式會搜尋的目錄，讓它以受影響程式的權限執行。公告的 CVSS v4 向量為 AV:L/AC:L/AT:N/PR:H/UI:N，分數 8.4；v3.1 為 6.7。這裡的本地存取與高權限條件不能省略。

讀者可能會問：既然 UI:N 代表不需使用者互動，為什麼官方還提醒不要把網頁命令貼進 Win+R 或 PowerShell？

因為漏洞評分描述的是漏洞利用條件，ClickFix 則描述如何誘導人員走到惡意檔案執行的那一步。不能拿向量中的一個欄位，替整條散布流程背書；也不能反過來因為有社交工程，就改寫公告的漏洞條件。現有公告沒有支持「任何遠端使用者都能無互動取得管理員權限」這種說法。

驗簽查的是檔案，載入時還有另一份檔案要決定

Microsoft 的 DLL 安全文件說明：動態載入若沒有指定完整路徑，系統會按搜尋規則尋找 DLL。攻擊者能控制其中一個候選目錄，而程式尚未找到合法 DLL 時，就可能載入攻擊者提供的檔案。

因此，排查時看到 EXE 簽章有效，不足以替它後續載入的 DLL 下結論。PowerShell 的 Get-AuthenticodeSignature回傳的是指定檔案的簽章資訊；檢查一個 EXE，沒有順便驗完整個執行中的程序。

對自己維護的 Windows 程式，我會把 code review 問題寫得更具體：這次 LoadLibrary 最後拿到哪個絕對路徑？那個目錄誰能寫？必要 DLL 不存在時，程式會停止，還是繼續往其他位置找同名檔？

Microsoft 建議使用完整路徑，或透過 LoadLibraryEx 的搜尋旗標、SetDefaultDllDirectories 等方式限制搜尋範圍。不過，完整路徑指向可被非預期使用者改寫的檔案，仍不能解決檔案來源問題。搜尋範圍與目錄寫入權限要一起檢查；這是本文的工程推論，不是聲稱 Siemens 修補內部採用了某一段 API 實作。

用自己的測試程式驗收，不下載事件樣本

若團隊要確認載入行為，可以在隔離測試機使用自己維護的測試版程式，以及只回報識別字串的無害測試 DLL。不要拿公告中的惡意檔案做日常驗收。

以下是建議的測試設計，尚未實跑：

  1. 在程式呼叫載入 API 前設中斷點，記錄傳入路徑與目前目錄。先確認實際載入點，不只檢查原始碼中看起來正確的設定值。
  2. 在測試允許的非信任目錄放置同名、無害的測試 DLL，再恢復執行。用模組載入紀錄確認實際選中的完整路徑；驗收標準是非信任目錄的副本不應被載入。
  3. 暫時讓核准的必要 DLL 無法取得，再跑一次。這次應明確失敗，不能因為另一處剛好有同名檔案就繼續啟動。若產品設計允許外掛搜尋，則必須另訂外掛來源與可寫入者的限制，不能把它當成同一條保證。
  4. 換回正常檔案，確認原有功能仍可運作。限制搜尋範圍後若有相容性問題，要找出依賴的路徑，不能直接恢復整個任意搜尋範圍來讓測試變綠。

這組測試只能驗收選定的載入路徑與測試案例，不能證明整套應用程式沒有其他載入入口。若有多處動態載入、外掛或延遲載入，必須逐一盤點。

工單不要只剩「簽章正常」四個字

今天可以先完成兩個明確交付：核對受管理安裝的版本，並請端點負責人搜尋異常路徑與父程序組合。已經找到可疑執行跡象的主機，保留證據並走事件應變流程；更新成功不應成為結案理由。

先前的 SubQuery 套件事件需要追查套件是否曾被載入；這次則提醒我們，即使執行檔身分正常，仍要追到實際載入的模組。下一次有人用「有合法簽章」替告警結案時，補問一句就好：那份 DLL 的路徑與來源，也查過了嗎？