新型 OT/IoT 网络武器：IOCONTROL

执行摘要

Team82 获得了一种定制的 IoT/OT 恶意软件 IOCONTROL 样本，该恶意软件被与伊朗有关的攻击者用来攻击以色列和美国的 OT/IoT 设备。

IOCONTROL 已被用来攻击各种类型的 IoT 和 SCADA/OT 设备，包括 IP 摄像头、路由器、PLC、HMI、防火墙等。受影响的一些供应商包括：Baicells、D-Link、Hikvision、Red Lion、Orpak、Phoenix Contact、Teltonika、Unitronics 等。

我们评估认为，IOCONTROL 是民族国家用来攻击民用关键基础设施的网络武器。

我们对 IOCONTROL 的分析包括深入研究恶意软件的功能以及与攻击者的命令和控制基础设施的独特通信渠道。

什么是 IOCONTROL 恶意软件？

据信，IOCONTROL 是针对西方物联网和运营技术 (OT) 设备的全球网络行动的一部分。受影响的设备包括路由器、可编程逻辑控制器 (PLC)、人机界面 (HMI)、防火墙和其他基于 Linux 的物联网/OT 平台。虽然该恶意软件据信是由威胁行为者定制的，但似乎该恶意软件足够通用，由于其模块化配置，它能够在来自不同供应商的各种平台上运行。

Team82 分析了从燃料管理系统中提取的恶意软件样本，据称该系统遭到与伊朗有关联的威胁行为者组织 CyberAv3ngers 的攻击，该组织还被认为对去年秋季的Unitronics 攻击负责。 

一波 IOCONTROL 攻击波涉及入侵数百个以色列制造的Orpak 系统和美国制造的Gasboy燃料管理系统，这些系统位于以色列和美国境内。该恶意软件本质上是为 IoT 设备定制的，但也对 OT 产生直接影响，例如加油站大量使用的燃油泵。 

此次袭击是以色列和伊朗地缘政治冲突的又一延伸。这些所谓的CyberAv3ngers被认为是伊朗革命卫队网络电子司令部 (IRGC-CEC) 的一部分，他们在 Telegram 上公开分享了这些燃料系统被攻陷的截图和其他信息。 

今年 2 月，美国财政部宣布对与 CyberAv3ngers 组织有关联的 6 名伊朗革命卫队中央司令部官员实施制裁，并提供1000 万美元的赏金，征求有关人员提供的身份识别或位置信息。 

我们对从 VirusTotal 获得的样本进行了分析（截至 2024 年 12 月 10 日，共检测到 21 次，而此前一段时间截至 2024 年 9 月仍未检测到任何此类恶意软件），得出的结论是，该恶意软件本质上是国家用来攻击民用关键基础设施的网络武器；至少有一名受害者是 Orpak 和 Gasboy 燃料管理系统。为了确保受感染设备与攻击者之间的安全通信，IOCONTROL 利用 MQTT 协议作为专用的 IoT 通信通道。攻击者能够伪装通过 MQTT 往返于攻击者的命令和控制基础设施的流量。

与此同时，CyberAv3ngers 已明确表示，他们将继续针对关键基础设施中以色列制造的技术。2023 年 10 月，美国和以色列的水处理设施遭到该组织的攻击。这些设施内的集成 Unitronics Vision 系列 PLC/HMI 设备成为攻击目标；攻击导致这些 OT 设备被毁坏。这些攻击可能是 CyberAv3ngers 的力量投射，表明他们有权访问这些设备，并希望引起人们对受影响地区水质的恐慌。 

ORPAK 系统上的 IOCONTROL 部署

在水利设施遭攻击的同时，CyberAv3ngers 在 Telegram 上发布消息，声称已攻击以色列和美国的 200 家加油站，特别是 Orpak 系统。攻击者发布了受攻击加油站主管理门户的截图，以及有关其目标和泄露数据的信息数据库。

这是 CyberAv3ngers 电报频道的截图，他们在其中讨论了针对 Orpak 燃料管理设备的攻击。

CyberAv3ngers 在 Telegram 上分享的截图显示他们已经获得了 ORPAK SiteOmat 燃料管理系统的访问权限。

专用的 CyberAv3ngers 脚本正在运行，据称会使 Orpak 系统崩溃。

在 CyberAv3ngers 声称入侵 Orpak 系统后，我们发现 WHOIS 记录表明该域名注册tylarion867mino[.]com于 2023 年 11 月 23 日。

攻击者将利用该域来建立命令和控制基础设施，以管理所有受感染的设备。 

2023 年 12 月，一个与以色列有关的黑客组织声称Gonjeshke Darande袭击并入侵了伊朗 70% 的加油站，并声称这是“对伊朗伊斯兰共和国及其该地区代理人的侵略的回应”。

虽然有关 CyberAv3ngers 针对 Orpak 设备发起攻击的报告时间跨度从 2023 年 10 月中旬到 2024 年 1 月下旬，但我们的团队从 VirusTotal 获得了一个公开的 IOCONTROL 样本，表明该组织在 7 月和 8 月重新启动了他们的目标活动。 

我们的研究博客介绍了针对多种 IoT/OT 设备（包括 Orpak 和 Gasboy 设备）的攻击的分析。此外，我们还将分析攻击中使用的 IOCONTROL 恶意软件、攻击者的命令和控制基础设施以及通过 MQTT 协议进行的通信。

ORPAK 系统设备

我们能够获得的样本是从与 Orpak Systems 关系密切的 Gasboy 燃料控制系统中提取的。目前尚不清楚在受影响的受害者系统上部署恶意软件的方法。

燃料控制系统是一个复杂的平台，由多个子系统组成，包括户外支付终端、打印机（用于收据）、泵和喷嘴控制以及其他外围设备（如管理和计费软件）。

GASBOY 燃油系统装置。来源：Spatco.com

燃料控制系统非常复杂，由许多子系统组成。来源：Gilbarco.com

IOCONTROL 隐藏在 Gasboy 的支付终端OrPT中。完全控制支付终端的攻击者意味着他们有能力关闭加油服务，并可能窃取客户的信用卡信息。

IOCONTROL 二进制分析

我们分析的 IOCONTROL 样本针对 Orpak Fuel 系统设备。此样本的哈希值为：1b39f9b2b96a6586c4a11ab2fdbff8fdf16ba5a0ac7603149023d73f33b84498。样本包含用于识别受害者实体的内部 GUID 值：  855958ce-6483-4953-8c18-3f9625d88c27。我们分析的样本是专门为 ARM-32 位 Big Endian 架构系统编译的。

IOCONTROL 的脱壳与仿真

观察VirusTotal中的恶意软件样本，9月份其所有沙盒引擎均未检测到该恶意软件；截至12月10日，共有21个检测到该恶意软件。

恶意软件样本的 VirusTotal 检测仪表板。

了解了这一点，我们在处理恶意软件和分析其内部结构时就格外谨慎。我们决定开始使用静态分析方法分析恶意软件。这种方法让我们得出结论：恶意软件执行时会运行内存中的解包程序。

静态分析耗时太长，耗费太多精力，因此我们决定将精力转向恶意软件样本的动态分析。这意味着我们必须安全地执行恶意软件样本并进行调试。

我们执行和解压恶意软件可执行文件的方法是模拟，具体来说是使用基于 Python 的 Unicorn CPU 模拟引擎。 

我们决定走这条路有两个原因：

该恶意软件样本是为古老的 ARM 32 位 BE CPU 架构编写的，这使得模拟成为执行和解压恶意软件样本的最佳解决方案。

我们需要找到一种在安全可控的环境中执行恶意软件的方法，这种方法不会感染我们的设置或在我们的系统上执行恶意活动。

与QEMU等其他引擎相比，Unicorn 为我们提供了对仿真更精细的控制；它不仅允许我们仔细检查恶意软件的执行流程，还允许我们完全控制恶意软件在系统调用和操作系统交互方面的功能。

模拟样本是一个渐进的过程，我们仔细检查了恶意软件的执行流程。这包括跟踪执行的代码并保存每个模拟轮次的内存映射。一开始，每一轮模拟都在启动样本执行后不久突然终止。这通常是由于恶意软件试图调用系统调用进行操作系统交互而导致的。Unicorn 提供了在各种架构和变体中执行模拟 CPU 指令的能力。但它不支持特定的操作系统基础设施，例如 Linux 或 Windows 等特定操作系统的系统调用实现。

每次我们遇到特定的系统调用尝试时，我们都会尝试了解其目的并实现我们自己的系统调用版本，以使执行能够继续，同时确保交互是安全的并且不会损害我们的测试环境。

例如，当可执行文件调用open和read系统调用从文件系统读取文件时，我们的指令执行钩子将触发并处理这些调用。在这种情况下，当系统open调用被调用时，我们的钩子会返回一个假fd值来识别所请求的文件。当在read系统调用上触发时，我们提供我们自己控制的定义内容。这样做使我们能够对恶意软件代码流进行细粒度访问。

来自 Python 仿真模块的代码片段展示了打开、读取和系统调用的实现。

在恶意软件执行过程中，内存解包过程分为两个阶段。第一阶段包括将实用程序代码例程解包到新映射的内存段中。第二阶段包括将恶意软件的构件（即主要可执行模块和恶意软件的配置）解包到适当的内存位置。

在我们的一次模拟迭代中，我们的执行流程开始在新映射的内存段上执行。这意味着此内存段有一个未打包的工件。检查该段的内存快照后，我们推测该恶意软件正在使用一种名为UPX 的开源打包程序解决方案，该解决方案可能已针对此恶意软件样本进行了专门修改。导致这种怀疑的触发因素是恶意软件开发人员未修改的字节序列，该序列未出现在恶意软件的未打包工件中：“ !XPU”，它是“ ”的小端版本UPX!。攻击者的这一失误帮助我们快速识别出 UPX 是打包程序。

解压后的工件快照，包含 UPX 魔法标头值的可疑小端表示。

为了研究，在获得恶意软件的脱壳版本后，我们使用良性 UPX 工具对其进行了加壳，并将其与原始样本进行了比较。我们注意到 UPX 相关功能应该放置的位置存在一些差异，例如神奇的UPX!字节串被更改为 ABC!。

将原始恶意软件样本（左段）与 UPX 打包文件（右段）进行二进制差异分析。

为了进一步支持这一结论，我们编译了一个忽略 CRC 校验和验证的 UPX 版本，并ABC用UPX字节序列修补了样本字节序列，从而使我们能够成功解压恶意软件样本。

我们推测攻击者以这种方式部署恶意软件是因为他们试图逃避检测，并以一种稳定而快速的方式隐藏其恶意植入和配置。这显然在不被自动检测引擎检测到方面有些有效，但并不是很复杂。

解密 IOCONTROL 的配置

成功解压恶意软件后，我们得到了两个文件：加密数据部分和可执行文件。在 IDA 中检查可执行文件时，我们注意到在代码的许多不同位置，它都使用来自加密部分的数据，并将其用于不同的操作，例如文件路径、要连接的 IP 地址等。

恶意软件从其配置中读取主机名/端口对，并使用它来连接到 MQTT 代理。

我们发现这个加密部分实际上是恶意软件的加密配置。每个加密配置条目由 150 个字节组成：1 字节长度（加密数据的长度，最大 149），加密数据最大 149 字节。 

为了解密恶意软件的配置，它使用解密函数，该函数接收一个索引，指定它希望从列表中解密哪个配置。这种技术可以最大限度地降低在恶意软件运行时从进程内存中提取解密配置条目的可能性。

在这个解密函数中，恶意软件从加密的配置条目中获取第一个字节。这个值用于表示特定加密配置条目的长度，在读取加密条目的原始字节后，恶意软件使用 AES-256-CBC 解密方案来提取实际的配置条目。

配置解密例程，从环境变量中获取密钥/IV 对。

解密之前，恶意软件会从存储在其字符串之一中的 GUID 中提取密钥和 IV 对，恶意软件会将其用于多种用途。提取的密钥和 IV 用于解密，并分别存储在环境变量0_0和中0_1。

密钥生成例程，对硬编码的 GUID 执行哈希和字符串操作。

我们可以看到，恶意软件获取存储在其内存中的 GUID（855958ce-6483-4953-8c18-3f9625d88c27），并使用 SHA256 对其进行哈希处理。AES-256-CBC 加密的密钥只是 GUID（22e70a3056aa209e90dc5a354edda2c1c3b88f1e4720dc6a090c4617a919447e）的哈希值（十六进制字符串）。这可能是攻击者的失误，他们搞混了，因为 AES-256 的密钥大小为 32 字节，但他们使用了 64 十六进制字符串。由于给定的密钥大于密钥大小，因此 AES-256-CBC 进程实际上只会使用前 32 个字节。用于加密的 IV 是该哈希值的子字符串（从索引 31 到索引 63）。再次强调，IV 太长，因此只使用了前 16 个字节。

我们的假设是，攻击者使用二进制修补恶意软件样本插入的唯一 GUID 来区分不同的受害者和/或活动。恶意软件的大部分参数都来自种子 GUID，这进一步支持了这一假设，而种子 GUID 可以通过二进制修补字符串轻松更改，而无需重新编译恶意软件。此外，该恶意软件使用物联网供应商标识符。例如，在我们的样本中，我们在解密配置中注意到 Orpak 名称，它标识了制造受到攻击的嵌入式设备的供应商。

总而言之，以下是恶意软件使用的环境变量，以及它们的使用方式和生成方式：

该恶意软件使用的部分配置列表。

通过 DoH 解析 IOCONTROL 命令和控制

掌握了配置后，我们继续分析恶意软件的行为。第一个配置中存储的 DNS 名称立即引起了我们的兴趣：

uuokhhfsdlk[.]tylarion867mino[.]com.

在撰写本报告时，域名 C2 地址正在解析为 IP 地址159[.]100[.]6[.]69。

跟踪恶意软件的执行流程，我们发现这确实是恶意软件用于与其 C2 通信的主机名。

首先，该恶意软件使用 Cloudflare 的服务器将主机名转换为 IP 地址。为了逃避检测，该恶意软件不使用 DNS 直接转换此主机名，而是DNS over HTTPS (DoH)通过 CloudFlare 的 API 进行转换。这是恶意软件用来避免被检测到的一种隐身技术，它通过发送明文 DNS 请求来展示它们与哪些 DNS 名称进行通信。相反，它们使用加密协议 (HTTPS)，这意味着即使存在网络窃听，流量也会被加密，因此它们不会被发现。

以下是对 Cloudflare 服务器的请求，查询攻击者的 C2 主机名：

~ curl --http2 --header "accept: application/dns-json" 
"https://1.1.1.1/dns-query?name=uuokhhfsdlk[.]tylarion867mino[.]com"

{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": false,
  "CD": false,
  "Question": [
  {
 "name": "uuokhhfsdlk[.]tylarion867mino[.]com",
     "type": 1
 }
 ],
  "Answer": [
    {
      "name": "uuokhhfsdlk[.]tylarion867mino[.]com",
      "type": 1,
      "TTL": 300,
      "data": "159[.]100[.]6[.]69"
    }
  ]
}

处理恶意软件 C2 主机名的 HTTPS 转换 DNS 的例程。

持久性

在连接到 C2 基础设施之前，恶意软件首先在设备上安装后门，以确保其持久性。为此，恶意软件添加了一个新的rc3.d启动脚本，该脚本将在设备重启时执行。后门位于/etc/rc3.d/S93InitSystemd.sh，包含以下 bash 脚本：

trap "rm -f $iocpid" EXIT
while true; do
if ! pidof "iocontrol" > /dev/null; then
    iocontrol >/dev/null 2>&1 &
fi
    sleep 5
done

除了这个后门之外，恶意软件还存储在iocontrol该/usr/bin目录中。

通过 MQTT 与 C2 通信

将此主机名转换为 IP 地址后，恶意软件采用第二个配置参数：8883，并将其用作连接 C2 的端口。端口 8883 通常由 MQTTs 通信协议使用，当进一步检查代码时，我们确实看到恶意软件确实通过此端口进行通信。

该恶意软件构建一个 MQTT CONNECT 数据包，启动其与 C2 的 MQTT 连接。

MQTT 协议

MQTT 协议是一种发布-订阅网络协议，用于在设备之间传输消息。它专为网络带宽有限或不可靠的环境而设计，因此特别适合物联网 (IoT) 应用。出于这些原因，以及为了更隐蔽，我们认为攻击者决定使用 MQTT 协议进行 C2 通信。

为了进行连接，恶意软件使用 MQTT 4.0，向 C2 发送三个不同的标识符：客户端 ID、用户名、密码。对于客户端 ID，恶意软件使用存储在其内存中的 GUID，用户名是环境变量3（源自 GUID），密码是环境变量4（也源自 GUID）。使用这些标识符，恶意软件向 MQTT 代理进行身份验证。

恶意软件的 MQTT 连接消息的重建。

连接到 MQTT 代理后，恶意软件会立即hello向以下主题发布一条“ ”消息：{GUID}/hello。此消息通知 C2 有新连接，并发送大量有关受感染设备的识别信息。在其 hello 消息中，恶意软件发送包含以下信息的 JSON：

{
  "hostname": "HOSTNAME",
  "current_user": "CURRENT_USER",
  "device_name": "DEVICE_NAME",
  "device_model": "DEVICE_MODEL",
  "timezone": "TIMEZONE",
  "firmware_version": "FIRMWARE_VERSION",
  "geo_location": "GEO_LOCATION",
  "version": "MALWARE_VERSION"
}

为了获取这些信息（例如，当前用户、主机名等），恶意软件使用操作系统命令。在此过程中，恶意软件libc通过使用dlopen参数进行调用来获取库的句柄libc.so.6。然后，恶意软件使用此句柄，使用 获取指向系统函数的指针dlsym，为其赋予函数名称system，最后使用此指针执行所需的操作系统命令。

恶意软件执行系统命令的方法。

对于恶意软件执行的每个操作系统命令，它都会构建以下命令：

OS_COMMAND > /tmp/{RANDOM_16_chars}.txt 2>&1

作为hello消息的一部分，恶意软件按以下顺序执行以下操作系统命令：

uname -v > /tmp/{RANDOM_16_chars}.txt 2>&1
hostname > /tmp/{RANDOM_16_chars}.txt 2>&1
whoami > /tmp/{RANDOM_16_chars}.txt 2>&1
date +%Z > /tmp/{RANDOM_16_chars}.txt 2>&1
uname -r > /tmp/{RANDOM_16_chars}.txt 2>&1

发送hello消息后，恶意软件会订阅 MQTT 主题 {GUID}/push。使用此主题，C2 会向恶意软件发送要执行的命令，恶意软件会在收到 MQTT 消息时调用的回调例程中执行这些命令。

支持的命令

在此例程中，恶意软件会解析收到的消息并提取恶意软件发送的命令。来自 C2 的每个命令都是五种不同类型之一，每种类型都由不同的操作码标识：

完成命令执行后，恶意软件使用主题发布响应{GUID}/output。

IOCONTROL 流程：简化

IOCONTROL 基础设施

该恶意软件的 C2 域名uuokhhfsdlk[.]tylarion867mino[.]com,解析为159[.]100[.]6[.]69

领域

该 C2 域名tylarion867mino[.]com于 2023 年 11 月 23 日注册。攻击者使用该域名建立了 C2 基础设施，从而可以命令和控制他们感染的所有设备。

攻击者的 C2 域名的 Whois 记录。

在撰写本报告时，已解析到 C2 域名地址159[.]100[.]6[.]69。该地址托管在德国，在端口 1883 和 8883 上运行 MQTT 服务，在端口 15672 上运行 RabbitMQ 管理服务器。与端口 8883 上的 C2 服务器的通信可能是受害者向 C2 报告，也可能是操作员访问服务器。

大约 2023 年的旧 DNS 记录显示，该域名ocferda[.]com正在使用中，并指向 C2 的同一 IP 地址159[.]100[.]6[.]69。

概括

我们的分析表明，IOCONTROL 恶意软件基于一个通用的 OT/IoT 恶意软件框架，用于嵌入式 Linux 设备，该框架可根据需要针对特定目标进行利用和编译。该恶意软件通过安全的 MQTT 通道与 C2 通信，并支持基本命令，包括任意代码执行、自我删除、端口扫描等。此功能足以控制远程 IoT 设备并在需要时执行横向移动。 

此外，IOCONTROL 具有通过守护进程安装和隐身机制实现的基本持久性机制，例如，初始有效负载使用修改后的 UPX 打包，恶意软件使用通过 HTTPS 的 DNS 尽可能隐藏其 C2 基础设施。

此特定样本是从 Gasboy/ORPAK 设备（一种燃料系统平台）中提取的。然而，IOCONTROL 被用来攻击各种类型的 IoT 和 SCADA 设备，包括来自 Baicells、D-Link、Hikvision、Red Lion、Orpak、Phoenix Contact、Teltonika、Unitronics 等不同供应商的 IP 摄像头、路由器、PLC、HMI、防火墙等。