Aviation Runway Cyber Range Security Case Study

3,740 0
English 简体中文 繁体中文 ภาษาไทย Tiếng Việt
Summary

This case study details a multi-stage Man-in-the-Middle (MITM) attack executed against the IEC 60870-5-104 OT control channel of an aviation runway lights management simulation system. The attack begins with reconnaissance via a compromised maintenance engineer's laptop, followed by a supply-chain compromise to embed malicious firmware into an IoT surveillance camera deployed within the isolated OT network. This tampered camera then performs ARP spoofing and real-time packet manipulation to alter runway light commands and suppress accurate state feedback to the HMI. The successful manipulation results in a denial of runway light control, causing aircraft takeoff delays and escalating into a safety-critical fuel-low situation for an inbound aircraft. The findings emphasize the critical need for robust network segmentation, rigorous supply-chain security, and comprehensive monitoring of OT control channels to defend vital aviation infrastructure.

[ PLC–HMI IEC 60870-5-104 OT 控制通道上的 MITM 攻擊 ]

現代機場非常依賴整合的 OT、IT 和 IoT 系統，以確保空中交通管制 (ATC) 安全且有效率的跑道運作。這些系統也已成為網路攻擊的潛在目標。在本案例研究中，我將使用迷你 OT 航空 CAT-II 機場跑道燈光管理模擬系統 (v_0.2.1) 來示範惡意的紅隊成員如何透過中間人 (MITM) 網路攻擊，利用網路靶場的 PLC-HMI IEC 60870-5-104 控制通道中的錯誤配置和弱點。

本案例研究旨在作為我們 IT/OT/IoT 網路安全研討會的一部分，展示現實世界系統中可能發生的六種不同的攻擊途徑。此情境假設攻擊者入侵塔台 ATC 控制室內未經授權的第三方 IoT 監視攝影機，並從那裡攔截和操縱人機介面 (HMI) 和可程式邏輯控制器 (PLC) 之間的 OT 流量。模擬的攻擊會導致跑道燈光控制暫時中斷，升級為空中交通管制服務中斷，最終造成飛機燃油不足的警示情況。

本案例研究包含以下 5 個部分：

  • 案例研究中使用的攻擊情境背景和網路安全假設。

  • 跑道燈光管理模擬系統的警告、警報和安全保護系統。

  • 跑道燈塔網路中的錯誤配置如何產生可利用的弱點。

  • 具有 MITM 控制通道操縱技術細節的逐步攻擊路徑。

  • 攻擊影響的示範及其在訓練事件應變團隊中的應用。

重要注意事項：本案例研究發生在受控的網路靶場環境中，其中故意注入漏洞和錯誤配置以用於訓練目的。在現實世界的航空系統中，安全保護措施更加完善，此處描述的大多數弱點都會得到解決。所展示的攻擊無法直接在運作中的機場系統上複製。

特別感謝：我要非常感謝專業航空安全專家Olivier Roubault 的建議、評論和實用建議，這些建議極大地幫助我們改進跑道燈光管理系統網路靶場和案例研究的設計和真實性。

# Author:      Yuancheng Liu
# Created:     2025/09/10
# Version:     v_0.2.1
# Copyright:   Copyright (c) 2025 Liu Yuancheng

簡介

本網路攻擊案例研究示範了如何結合多種攻擊技術來操縱機場塔台中跑道燈光和指示器控制 HMI 與負責控制跑道起飛等待燈的 PLC 之間的控制資料流通道。透過利用這些弱點，攻擊者能夠造成飛機降落作業的拒絕或延遲，直接影響空中交通管制服務。本案例研究將涵蓋六種類型的網路攻擊途徑，包括：

  • IOT 裝置的供應鏈入侵

  • 惡意韌體更新和錯誤配置

  • IEC61850-5-104 協定的缺陷

  • 竊聽和封包篡改

  • 中間人控制劫持

  • 元件層級的阻斷服務

整個案例研究和示範都在最新版本的迷你 OT 航空 CAT-II 機場跑道燈光管理模擬系統上進行，該系統專為研究、訓練和網路靶場演練而設計。此處提供的所有攻擊情境和技術僅用於教育目的，支援不同層級的 IT/OT/IoT 網路安全訓練和以 ICS 為重點的課程。

航空網路靶場簡介

迷你 OT 航空 CAT-II 機場跑道燈光管理模擬系統是一個緊湊型網路靶場平台，旨在模擬四個不同層級的 OT 環境，如以下系統結構圖所示：

Figure-01: Aviation Cyber Range Architecture Diagram version v0.2.1 (2025)

它提供從 OT-Level 0 物理過程（純跑道裝置）的模擬模組，例如 ALS 和 ILS 燈、機場監視雷達 (ASR) 系統、VHF 通訊和攝影機到 OT-Level 3 運營管理區，例如塔台控制和監控 HMI 系統。所有系統的設計都遵循美國聯邦航空管理局 (FAA) ATC「通用標準」。該平台模擬了用於機場 ATC 的四個SCADA 系統：

  • CAT-II 跑道燈光系統：核心系統模擬 11 種跑道燈光和視覺指示器。

  • 機場監視雷達系統：輔助系統模擬 3 種雷達。

  • 無線電通訊系統：輔助系統模擬 VHF/UHF 飛行員-塔台和電話塔台-地面通訊。

  • 監視攝影機系統：降落和起飛跑道飛機監視器 IP 攝影機系統。

目前，網路靶場已更新至 v_0.2.1 版本，如需更多介紹，請參閱 v_0.0.1 介紹文件：https://www.linkedin.com/pulse/aviation-runway-lights-management-simulation-system-yuancheng-liu-5rzhc

示範系統環境配置

在現實世界的機場中，IT 和 OT 基礎設施非常強大、隔離且設計用於抵抗目前已知的大多數網路攻擊。為了為本案例研究創建一個實用的訓練環境，我們故意在我們的網路靶場平台中引入了假設的弱點和錯誤配置。這些假設使我們能夠探索攻擊者如何利用保護較少的系統中的漏洞，而不會暗示此類缺陷存在於運作中的機場網路中。

示範網路配置（見上圖）由四個不同的子網路和總共 17 個虛擬機器 (VM) 組成，如下所示：

Figure-02: Case Study OT network topology diagram, version v0.2.1 (2025)

  • 綠隊子網路 – 代表裝置和 PLC 之間的物理世界連接。紅隊攻擊者無法直接存取此子網路。

  • 藍隊子網路 1 – 模擬跑道塔台控制室和 PLC 之間的通訊網路。它受到 IP 路由控制的保護，並且攻擊者也無法直接存取。

  • 藍隊子網路 2 – 代表跑道控制塔的隔離網路，包括 SCADA HMI 和監控系統。雖然攻擊者無法直接連接，但此子網路可能會透過維護活動或錯誤配置的裝置間接暴露。

  • 紅隊子網路/網際網路 – 模擬攻擊者的環境，包括 C2 基礎設施和受入侵的第三方 IoT 裝置。攻擊者無法在不利用中間路徑的情況下直接橋接到藍隊子網路 2。

本模擬中的一個關鍵網路存取設計規則是沒有人可以同時存取攻擊者的環境和隔離的 OT 網路。

案例研究情境錯誤配置假設

根據先前的環境介紹，我們了解到紅隊攻擊者無法即時存取 OT 網路的任何部分。相反，攻擊者必須依靠粗心的維護工程師和他受入侵的筆記型電腦來彌合差距。這創造了一種真實的內部威脅途徑，突顯了端點衛生不良的風險。

我們定義了關於本網路靶場系統中弱點和錯誤配置的五個關鍵假設：

  • 假設 1：粗心的維護工程師將他的筆記型電腦連接到網際網路，使攻擊者有機會安裝間諜木馬並獲得有關機場的一些關鍵資訊。

  • 假設 2：同一台筆記型電腦稍後會實際連接到隔離的 Level-3 跑道 OT 網路進行測試，使預先安裝的木馬能夠在控制環境中運作。

  • 假設 3：離開控制塔後，維護工程師將他的筆記型電腦重新連接到網際網路，使攻擊者能夠提取木馬收集的敏感網路資訊和通訊樣本。

  • 假設 4：攻擊者執行供應鏈入侵，將惡意程式碼嵌入到 IoT 攝影機的韌體中，然後該攝影機充當 OT 環境中的隱形存取點。

  • 假設 5：錯誤配置將第三方 IoT 監視攝影機放置在與跑道燈光控制 HMI 相同的子網路上，維護工程師使用惡意韌體更新攝影機，從而產生意外的暴露點。

這些假設雖然對於現實世界的航空系統來說是不切實際的，但提供了一個受控、靈活的訓練場，我們可以在其中模擬供應鏈入侵、錯誤配置濫用、內部風險和 OT 特定的攻擊途徑，例如IEC104 控制通道的 MITM 操縱。

案例研究攻擊情境和路徑

下圖顯示了本案例研究中使用的模擬攻擊路徑。它顯示了攻擊者（從受入侵的維護筆記型電腦和篡改的 IoT 攝影機開始）如何在PLC ↔ HMI IEC-104 控制通道上建立中間人 (MITM)，以修改跑道等待燈命令資料 ASDU 區段，導致起飛延遲並迫使另一架進場飛機在等待航線中盤旋，直到發出燃油不足警報。

Figure-03: Case Study Attack Scenario and Path diagram, version v0.2.1 (2025)

端到端攻擊在下圖中標記的以下階段時間軸 (T1 → T13) 中展開。每個步驟都描述了攻擊者的行為、受入侵的維護工程師作為不知情的內部人員的角色，以及用於攔截 OT 流量的技術方法。

  • 步驟 T1 — 初始入侵和信標：攻擊者使用間諜木馬感染維護工程師的筆記型電腦（透過網路釣魚、惡意廣告或預先入侵）。木馬安裝網路掃描、封包捕獲有效負載，並等待來自攻擊者 C2 基礎設施的命令。當筆記型電腦在線上時，捕獲的遙測資料和封包會洩漏到 C2。

  • 步驟 T2 — 對 OT 的物理存取：維護工程師在不知道感染的情況下，斷開與網際網路的連線，並將筆記型電腦帶入跑道塔台室以執行維護任務。他將筆記型電腦插入連接到隔離的 OT 環境的塔台 RJ45 測試埠。

  • 步驟 T3 — OT 內部的本地偵察：連接後，木馬會被動地記錄受害者筆記型電腦和 Level-1 跑道 PLC (PLC01) 之間的網路流量，捕獲用於等待燈控制的 IEC-104 封包、定址和序列模式。

  • 步驟 T4 — 資料返回和分析：離開塔台並重新連接到網際網路後，筆記型電腦會將收集的封包捕獲上傳到攻擊者的 C2。攻擊者下載這些捕獲以進行離線分析。

  • 步驟 T5 — 攻擊開發：使用捕獲的流量和任何洩漏的文件，攻擊者對 IEC-104 訊息、HMI/PLC IP 和控制位元進行逆向工程。他們開發了一種 MITM 常式，能夠剖析和修改特定的 IEC-104 命令和回應。攻擊者將此 MITM 有效負載嵌入到第三方 IoT 監視攝影機的「自訂」韌體映像中。

  • 步驟 T6 — 供應鏈交付：攻擊者執行供應鏈或物流技巧，以使一台攝影機刷入惡意韌體並交付到維護流程中。

  • 步驟 T7 — 裝置更換：維護工程師（或現場承包商）更換塔台中損壞的攝影機，而無需檢查其韌體或網路位置。

  • 步驟 T8 — ARP 欺騙和流量重新導向：部署後，惡意攝影機會啟動並執行 ARP 欺騙/本地路由操縱，以將自身定位為 PLC01 和 HMI 之間的透明 MITM，導致流量流動 PLC01 → 攝影機 → HMI。

  • 步驟 T9 — 封包剖析和觸發邏輯：攝影機的 MITM 常式會剖析即時 IEC-104 框架，並等待特定的命令/序列（「觸發器」），該命令/序列指示操作員正在發出起飛等待燈變更。

  • 步驟 T10 — 命令篡改（起飛受阻）：當塔台操作員按下 HMI 按鈕以關閉起飛等待燈OFF（允許飛機開始起飛）時，MITM 會攔截並翻轉相關的控制位元，因此傳遞到 PLC01 的命令指示ON（保持）。飛行員看到物理燈光，將飛機保持在起飛等待區。

  • 步驟 T11 — 狀態回饋抑制：同時，MITM 修改 PLC → HMI 狀態報告，以便 HMI 顯示正常/預期的 PLC 狀態。這會對塔台操作員隱藏操縱，並阻止操作員採取糾正措施。

  • 步驟 T12 — 級聯運營影響：在最後進場的進場飛機（飛機 2）觀察到跑道被佔用（或收到與跑道被佔用一致的 ATC 指示），並且必須中止/執行錯過的進場，爬回等待航線。

  • 步驟 T13 — 安全升級：在等待航線中長時間盤旋後，進場飛行員向 ATC 宣告燃油不足狀況，促使優先處理和安全事件。

攻擊路徑示範了混合攻擊（結合端點入侵、供應鏈篡改和 OT 感知的 MITM）如何產生危險的運營結果，即使主要 OT 網路設計為隔離的。以上所有步驟都在我們的網路靶場中在受控條件下執行；它們僅旨在突顯攻擊機制、偵測機會以及用於訓練和研究的緩解策略。

網路靶場警告和警報系統

在我逐步介紹攻擊示範之前，了解網路靶場中內建的安全保護機制也很重要。這些機制模擬了現實世界的塔台 ATC 保護措施，因此您可以了解為什麼攻擊者必須執行特定的偵察和繞過操作才能保持隱蔽。

目的和高階行為：我們模擬器中的 PLC 和 HMI 實作自動狀態驗證和分層的警告/警報產生系統。每當操作員發出控制動作（例如，開啟跑道或進場燈以釋放狀態）時，PLC 會將命令狀態與燈光狀態感測器回饋進行比較。任何不匹配或異常情況都會被標記並推送到塔台 HMI 和物理世界模擬器顯示器，以便操作員可以快速偵測和回應故障。PLC 燈光感測器和控制邏輯遵循此 PLC 控制文章中的相同邏輯：https://www.linkedin.com/pulse/use-plc-remote-control-circuit-breaker-power-system-yuancheng-liu-7ljxc，目前版本提供 11 種跑道警告、18 種跑道警報和 4 種飛機警報。

如何視覺化警告和警報

  • 物理世界模擬器直接在模擬設備（例如，跑道燈或信標）上覆蓋閃爍的警告/警報圖示，以便網路靶場使用者立即看到受影響的元件。

  • HMI在專用的警告和警報指示器面板中鏡像這些通知，其中警報閃爍並提供上下文資訊（類型、受影響的裝置、時間戳記）。

實體世界模擬器 (真實警告與警報) 對應到人機介面 (偵測到的警告與警報) 如下所示：

Figure-04: Cyber Range Warning & Alert System diagram, version v0.2.1 (2025)

偵測邏輯範例：

  • 操作員按下控制按鈕 → 人機介面傳送 IEC-104 控制命令 → PLC 啟動裝置並讀取本地感測器 → PLC 將實際狀態回報給人機介面。

  • 如果在設定的逾時或容許範圍內，PLC 感測器狀態 ≠ 命令狀態，則 PLC 會發出警報；如果操作員動作需要注意但不重要，則可能會顯示警告。PLC/HMI 遵循與我們的 PLC 遠端控制範例中使用的相同感測器/控制邏輯。

警報與警告目錄

  • 跑道警告 (11) — 例如，起飛保持燈已啟動；信標塔電源警告；跑道邊緣燈關閉；警示區餘燼燈已啟動 ...

  • 跑道警報 (18) — 跨越進場燈、臨界燈、PAPI、滑行道指示燈、雷達天線和 VHF 天線的詳細電源/狀態不符和感測器故障警報 ...

  • 飛機警報 (4) — 例如，飛機燃料不足、飛機緊急爬升、雷達接近、跑道燈衝突 ...

這些類別提供多層次的情境感知：警告用於操作員注意，警報通常需要立即採取事件回應程序。

操作回應

當出現警告時，預期操作員會仔細檢查實體狀態並採取更正措施。當發生警報時，操作員必須啟動事件回應程序 (隔離、驗證感測器、回溯命令、呼叫維護等)。在網路攻擊期間，攻擊者需要消除或規避這些保護措施，抑制或偽造 PLC → 人機介面回饋，以便人機介面繼續顯示「正常」，儘管實際裝置狀態發生變化。

 

攻擊情境示範

在本節中，我們逐步介紹攻擊者的劇本：使用的工具和有效負載 (高階)、告知攻擊邏輯的封包層級分析，以及從初始入侵到擾亂跑道運作的即時 MITM 操作，對手執行的關鍵動作。

每個關鍵步驟都將攻擊者的意圖與可觀察的技術產物 (PCAPs、IEC-104 ASDU 欄位、裝置行為) 配對，以便防禦者可以了解攻擊如何運作以及存在哪些偵測機會。

步驟 T1 → T2 — 初始入侵與信標

此示範章節涵蓋攻擊者的前兩個階段：

  • (1) 在維護工程師的筆記型電腦上靜默植入輕量級竊聽器，

  • (2) 等待工程師將受感染的端點帶入隔離的 OT 環境，以便植入程式可以捕獲 PLC 到受害者筆記型電腦的流量。

使用的工具組：攻擊者使用我開發的紅隊工具組 — Project Ninja RT Framework (RTC2 & Trojan-Malware Cyber-Attack Simulation System)。Project Ninja 提供一個 C2 主控台，其中包含可以推送到目標的模組化有效負載，包括一個小型「輕型代理程式」，專為長時間封包捕獲和外洩而設計。工具組工作流程如下圖所示。

Figure-05: Project Ninja RT Framework Workflow diagram, version v0.2.1 (2025)

如需有關此攻擊系統的詳細介紹，您可以查看此文件：https://www.linkedin.com/pulse/project-ninja-framework-rtc2-trojan-malware-cyber-attack-liu-loihc

感染與有效負載部署 從 C2 網路木馬程式控制儀表板，攻擊者列舉受害者筆記型電腦並選擇輕型代理程式有效負載 (主控台中的功能 #9)。使用 GUI，攻擊者設定捕獲參數：

  • 目標 NIC：ethernet-5 (筆記型電腦本地 RJ45 介面，工程師稍後將其連接到塔式測試 RJ45 連接埠)

  • 捕獲持續時間/間隔：43,200 秒 → 12 小時 (代理程式將捕獲分割成多個 pcap 檔案)

  • 捕獲後行為：在排定的錄製完成後自動移除有效負載模組

Figure-06: Attacker Active EavesDrop Victim's traffic function, version v0.2.1 (2025)

安裝有效負載後 (步驟 T1)，攻擊者會等待排定的維護時段。在下一個工作日，維護工程師會中斷與網際網路的連線，進入跑道塔台，並將筆記型電腦插入隔離的藍隊子網路 2 RJ45 測試連接埠 (步驟 T2)。在該工作階段期間，植入程式會完全按照計畫捕獲受害者筆記型電腦 ↔ PLC 流量 (起飛/保持燈測試和狀態報告)。

部署後，木馬程式以低可見度模式執行，並定期嘗試向攻擊者的 C2 發送信標，以接收命令並在外洩筆記型電腦重新獲得網際網路連線時收集到的 pcaps。

步驟 T3 → T4 — 資料傳回、分析與攻擊決策

維護工作階段結束後，工程師返回家中後重新連線到網際網路，植入的木馬程式會向 C2 發送信標，並在外洩攻擊者使用內建的「02 — 從受害者竊取檔案到 C2-DB」功能時捕獲的資料 (如下所示)。

Figure-07: Attacker Steal file from the victim laptop to C2, version v0.2.1 (2025)

任務完成後，上傳的 PCAPs 會出現在 C2 檔案儲存區中 (如下所示)，攻擊者會將它們從 C2 下載到他的本地電腦以進行離線分析。

Figure-08: Attacker download the pcap file C2, version v0.2.1 (2025)

取得流量封包記錄「eavesdrop_record-07_13_09_2024.pcapng」後，攻擊者開始分析封包資料，並發現 PCAPs 包含一些第 2/3 層流量和 IEC-104 框架，這些框架是在筆記型電腦連接到隔離的藍隊子網路時捕獲的。分析期間恢復的關鍵產物包括：

  • IEC-104 ASDU 控制框架 (從筆記型電腦到 PLC 的命令請求，人機介面也使用它來控制 PLC)。

  • PLC → 筆記型電腦狀態報告 (測量/品質點，PLC 也可能使用它來控制人機介面)。

  • 人機介面和 PLC 的 IP 位址和對應 (例如，PLC01 = 10.10.20.11)。

  • IEC-104 工作階段使用的序列/時序模式和 APCI 計數器。

發現的協定與環境限制

根據文件和分析，攻擊發現仔細的封包檢查揭示了幾個重要的防禦因素，這些因素限制了簡單的攻擊選項：

  • PLC 寫入白名單 PLC 強制執行允許寫入原則白名單，以確保只有人機介面機器可以將 PLC 狀態變更命令傳送到 PLC，以防止錯誤命令注入攻擊，除非攻擊者可以繞過 PLC 存取控制。

  • 測量點持久性：燈光狀態維護在離散的測量 IOA 中，預期由 PLC 邏輯更新；僅僅注入錯誤的資料請求將會被 PLC 直接拒絕。

  • APCI 序列/確認計數器：IEC-104 在其 APCI 標頭中使用 Tx/Rx 序列號 (傳送/接收索引)。除非這些序列計數器與即時人機介面↔PLC 工作階段正確同步，否則先前捕獲的框架的簡單重播將會失敗，這對於封包重播攻擊來說幾乎不可能完全符合舊記錄封包的序列。

Figure-09: IEC 60870-5-104 APCI message sequence, version v0.2.1 (2025)

IEC 104 記憶體點變更規則文件：https://infosys.beckhoff.com/english.php?content=../content/1033/tf6500_tc3_iec60870_5_10x/984444939.html&id=

由於這些限制，攻擊者得出結論，無論是盲目錯誤注入還是簡單重播都無法可靠地實現隱蔽控制。他唯一的辦法是進行中間人攻擊，以修改從人機介面傳送到 PLC 的有效資料。

從捕獲的流量中，攻擊者找到與保持燈控制相關的確切 ASDU 元素和 IOA，如下所示：

Figure-10: HMI to PLC IEC 60870-5-104 ASDU requset data, version v0.2.1 (2025)

  • 控制 ASDU 參考 PLC 控制索引11。

  • 燈光控制的可變 IOA 為13。

  • 操作員的「逐步提升」控制表示為 ASDU 內的特定控制值 (val=02)。

攻擊者還觀察到從 PLC 到人機介面的讀回模式，如下所示：

Figure-11: PLC to HMI IEC 60870-5-104 ASDU response data, version v0.2.1 (2025)

當發出 UP 命令以變更燈光狀態時，PLC 也會取得感測器值，然後儲存到測量 IOA 1 轉換 (OFF → ON)，稍後人機介面會透過單獨的 IEC-104 讀取/報告序列讀回。

將各個部分放在一起，攻擊者對可行的攻擊策略進行建模：為了保持隱蔽，他們必須攔截並更改 IEC-104 交換的兩個方向 — 人機介面 → PLC 控制 ASDU (以翻轉命令) 和 PLC → 人機介面測量/報告 ASDU (以保持人機介面顯示一致)。攻擊者在攻擊假設圖中草繪了 MITM 邏輯和所需目標 (ASDU RCO 控制欄位和 ASDU SPI/狀態報告欄位)，如下所示：

Figure-11: MITM attack assumption diagram, version v0.2.1 (2025)

 

步驟 T5 → T7 — 攻擊開發與部署

在分析捕獲的 IEC-104 流量並識別與保持燈控制相關的確切 ASDU 欄位和 IOA 後，攻擊者選擇實施路徑內修改策略：保持隱蔽的唯一可行方法是位於人機介面和 PLC 之間，並更改兩個方向的訊息。

  • 人機介面 → PLC：修改控制請求，使操作員的「逐步提升/允許」變為「逐步降低/保持」(或反之亦然)。

  • PLC → 人機介面：反轉讀回/狀態報告，以便人機介面繼續顯示正常狀態，並且不會發出警告/警報。

由於藍隊子網路 2 與網際網路隔離，因此對手沒有嘗試從外部紅隊網路進行直接攻擊，而是使用受感染的第三方 IoT 攝影機作為實體媒介來實現該路徑內位置。一旦連接到與燈光控制人機介面相同的子網路，篡改的攝影機會透過宣傳誤導性的本地網路路由資訊 (例如，偽造的 ARP 對應) 來定位自己，以觀察和影響人機介面↔PLC 流量，以便流量透過裝置重新導向。攻擊流程圖如下所示：

Figure-12: MITM attack flow diagram, version v0.2.1 (2025)

為了在此攻擊示範中建立 MITM 有效負載，我們使用 Ettercap，它是基於 Linux 的全面中間人攻擊套件，用於實施 ARP 欺騙，並使用 Ettercap 篩選器來分析連接埠2042 流量並進行位元替換。如需詳細的 IEC104 ASDU 資料序列，您可以參考此說明：https://www.linkedin.com/pulse/python-virtual-plc-simulator-iec-60870-5-104-protocol-yuancheng-liu-bov7c

如果人機介面傳送逐步提升[\x02] 變更為逐步降低[\x01] (或反之亦然)，攻擊者想要修改控制C_CT_TA_1 步驟資料。為了實現這一點，我建立了 Ettercap 位元修改篩選器，如下所示：

if (ip.proto == TCP && ip.src = '10.10.20.11' && tcp.src == 2042 && ip.dst == '10.10.20.22') {
    if (search(DATA.data ,"\x3c\x01\x06\x00\x0b\x00\x0d\x00\x00\x02")) {
        replace("\x3c\x01\x06\x00\x0b\x00\x0d\x00\x00\x02", "\x3c\x01\x06\x00\x0b\x00\x0d\x00\x00\x01");
        msg("Modify the take off light on signal.\n");
        exit();
    }
       if (search(DATA.data ,"\x3c\x01\x06\x00\x0b\x00\x0d\x00\x00\x01")) {
        replace("\x3c\x01\x06\x00\x0b\x00\x0d\x00\x00\x01", "\x3c\x01\x06\x00\x0b\x00\x0d\x00\x00\x02");
        msg("Modify the take off light off signal.\n");
        exit();
    }
 }

當起飛保持燈感測器將燈光狀態傳送回人機介面時，攻擊者需要將 PLC 回應燈光 ON 狀態變更為 OFF (或反之亦然)。為了實現這一點，我建立了 Ettercap 位元反轉篩選器，如下所示：

if (ip.proto == TCP && ip.src = '10.10.20.22' && tcp.dst == 2042 && ip.dst == '10.10.20.11') {
    if (search(DATA.data ,"\x01\x01\x05\x00\x0b\x00\x01\x00\x00\x01")) {
        replace("\x01\x01\x05\x00\x0b\x00\x01\x00\x00\x01", "\x01\x01\x05\x00\x0b\x00\x01\x00\x00\x00");
        msg("reverse the take off light on signal.\n");
        exit();
    }
        if (search(DATA.data ,"\x01\x01\x05\x00\x0b\x00\x01\x00\x00\x00")) {
        replace("\x01\x01\x05\x00\x0b\x00\x01\x00\x00\x00", "\x01\x01\x05\x00\x0b\x00\x01\x00\x00\x01");
        msg("reverse the take off light off signal.\n");
        exit();
    }
}

完成篩選器後，將篩選器檔案編譯為有效負載*.ef 檔案，Ettercap 可以直接載入：

etterfilter arp_mitm.filter -o mitm.ef

然後，攻擊者按照此範例將此邏輯惡意有效負載封裝到最小韌體更新元件中，並將其整合到攝影機映像中：https://www.linkedin.com/pulse/ot-cyber-attack-workshop-case-study-06-replay-safety-surveillance-gcgxc，並在攝影機基本韌體啟動指令碼中新增 ARP 欺騙控制的自動執行命令，其中包含藍隊 2 子網路路由器 IP 位址：

sudo ettercap -T -q -F mitm.ef -M ARP /10.10.20.1//

完成所有操作後，自訂的 IoT 攝影機會交付到維護工作流程中，並由不驗證韌體或網路組態的維護工程師以實體方式安裝在塔台中。一旦在 OT LAN 上啟動，攝影機就會開始本地路由操作和選擇性 ASDU 替換，僅對狹義定義的觸發模式採取行動 (以減少雜訊並降低偵測機率)。

步驟 T8 → T11 — MITM 攻擊以延遲飛機起飛

此階段描述在塔台中安裝篡改的 IoT 攝影機且攻擊者的路徑內邏輯生效之後發生的情況。以下敘述將正常操作員/PLC/HMI 行為與 MITM 主動操作命令和狀態流量時操作員觀察到的情況進行對比。

正常塔台運作 —「允許起飛」(基準)

當運作正常且跑道暢通時，塔台操作員的飛機起飛控制如下所示：

Figure-13: Tower operator's plane take off control flow diagram, version v0.2.1 (2025)

  • 塔台操作員在人機介面上發出起飛保持燈 OFF 命令，以允許飛機開始起飛。

  • 人機介面將 IEC-104 控制傳送到 PLC；PLC 會關閉裝置上的跑道起飛保持燈，並將感測器狀態回報給人機介面。

  • 實體模擬器 (或真實裝置) 顯示燈 OFF；人機介面跑道狀態面板和電源控制指示器都反映 OFF 狀態；未顯示起飛警告。

正常塔台運作 —「保持起飛」(基準)

當運作正常且跑道需要保持關閉時，塔台操作員的飛機起飛控制如下所示：

當有理由暫停起飛時（例如，另一架已降落的飛機尚未在滑行道上移動），塔台操作員的飛機起飛保持控制如下所示：

Figure-14: Tower operator's plane take off holding control flow diagram, version v0.2.1 (2025)

  • 操作員透過 HMI 至 PLC 啟動 起飛保持燈 ON。

  • PLC 更改物理世界模擬器的起飛保持燈，起飛飛機在準備區域等待。

  • HMI 從 PLC 取得感測器資料，並在其跑道面板上更新 2 條紅線。

  • HMI 警告指示器區域顯示起飛保持警告，以識別飛機正在警告起飛。

MITM Active — 攻擊如何改變行為

一旦惡意攝影機成為路徑中的設備，它會選擇性地攔截 HMI ↔ PLC 交換，並且每次操作員更改起飛燈時執行兩個協調動作。

  • 修改外發控制命令 (HMI → PLC)：MITM 會翻轉或替換操作員預期的控制動作，因此 PLC 接收到的命令與操作員發出的命令不同（例如，操作員按下 OFF，但 PLC 接收到 ON—或反之亦然）。

  • 偽造/更改 PLC 回讀 (PLC → HMI)：在 PLC 的真實感測器狀態變更（或未變更）後，MITM 立即修改 PLC → HMI 報告，以便 HMI 顯示預期值（操作員期望看到的值），從而防止主控台上出現警報或明顯的狀態不符。

觀察結果如下所示：

Figure-15: MITM Active observation flow diagram, version v0.2.1 (2025)

  • 塔台操作員按下 HMI 上的保持燈關閉按鈕，以允許 plane1 起飛。

  • 物理燈保持與操作員認為的相反狀態（例如，操作員將其關閉，但它在現實世界中保持開啟）。因此，保持點的飛機不會啟動起飛。

  • HMI 顯示正常/預期狀態（電源關閉），因為 MITM 操縱 PLC → HMI 報告以隱藏不符。操作員沒有看到任何異常情況，並假設命令已成功。

  • 電源控制面板可能會指示預期的命令狀態（因為該指示器反映了操縱的回饋），從而進一步說服操作員跑道已淨空。

  • 警告訊息也不會觸發，以確認沒有飛機處於起飛保持狀態。

現在，IoT 攝影機的中間人攻擊已延遲了飛機起飛程序。

 

Step-T12 → T13 — 級聯運營影響和安全升級

當 MITM 攻擊成功延遲 plane1 起飛程序，以阻止塔台 HMI 了解真實的跑道狀態時，運營影響會迅速從局部設備故障級聯到航空安全事件，如下所示：

Figure-16: Plane2 cancel landing and climb up, version v0.2.1 (2025)

  • 一架進場飛機 (Plane-02) 到達最後進場模式，而離場飛機 (Plane-01) 仍停留在離場保持點，因為物理起飛燈從未關閉。plane02 飛行員從雷達和視覺偵測到跑道佔用情況。

  • 進場飛行員執行緊急錯過進場/重飛（中止降落並爬回已發布的保持模式），以避免可能的碰撞。

  • Plane-02 重新進入保持模式，並且可能會在其他交通工具後面進行向量或排序；由於飛行保持在空中的時間比計劃的長，因此燃料消耗會增加。

在延長的盤旋後，進場飛行員向 ATC 宣告 燃料不足 狀況。這會立即升級航班的優先順序，並觸發緊急處理/降落排序。模擬器會顯示燃料不足警報和由此產生的運營升級。（如下面的物理世界模擬器所示）

Figure-17: Plane2 fuel-low alarm, version v0.2.1 (2025)

最後，MITM 攻擊確實造成了級聯運營影響，並導致了安全升級事件。

事件回應：當 plane-02 向塔台報告燃料不足時，操作員啟動事件回應程序，以確認跑道的目前狀態，引導 plane01 或飛機拖車將 plane01 拖到滑行區域，然後引導 plane-02 降落。

防禦與結論

在示範了如何透過利用網路範圍環境中的錯誤配置和受損的 IoT 設備，對航空跑道燈光控制系統執行多階段中間人 (MITM) 攻擊後，我們可以為防禦者提供簡短的檢查清單，以降低升級風險並切斷可能的網路攻擊鏈：

  • 維護跑道狀態驗證的獨立冗餘（輔助感測器路徑、隔離的攝影機饋送）。

  • 對將連接到 OT VLAN 的任何設備強制執行嚴格的設備加入和韌體驗證。

  • 實施快速隔離功能（網路存取控制、交換器連接埠停用）以快速移除可疑端點。

  • 建立並定期執行手動跑道控制程序，以便操作員可以在調查技術根本原因的同時安全地繼續運營。

該模擬說明了此類攻擊攔截和操縱 IEC 60870-5-104 OT 協定流量的潛力，從而導致跑道燈光控制拒絕、飛機起飛延遲，並最終導致進場飛機的安全關鍵燃料不足情況。雖然該情境依賴於故意注入的漏洞以用於訓練目的，但它強調了強大的網路分段、嚴格的供應鏈安全以及對 OT 控制通道的全面監控的關鍵重要性。最終，此練習可作為訓練事件回應團隊的寶貴工具，並強調需要分層防禦來保護重要航空基礎設施免受新興的混合 IT/OT/IoT 網路威脅。

感謝您花時間查看文章詳細資訊，如果您有任何問題和建議或發現任何程式錯誤，請隨時給我留言。如果您能提供一些評論並分享任何改進建議，以便我們改進工作，將不勝感激 ~

last edit by LiuYuancheng ([email protected]) by 13/09/2025 if you have any problem, please send me a message.

 

 

  RELATED

No related programming articles found. Browse all programming tutorials and articles.

  COMMENTS

0

No comment for this article.