ICEDIDs 网络基础设施依然活跃

Elastic 安全实验室详细介绍了如何使用开源数据收集和 Elastic Stack 来分析 ICEDID 僵尸网络 C2 基础设施。

19分钟阅读攻击模式
ICEDIDs network infrastructure is alive and well

关键要点

  • ICEDID 是一款功能齐全的木马程序,它使用 TLS 证书固定来验证 C2 基础设施。
  • 虽然该木马程序已被追踪数年,但它仍然相对畅通无阻地运行。
  • 可以结合使用开源收集工具来追踪 C2 基础设施。

有关 ICEDID 配置提取器和 C2 基础设施验证器的信息,请查看我们详细介绍此内容的帖子

前言

ICEDID,也称为 Bokbot,是一种模块化银行木马,于 2017 年首次被发现,并在过去几年中一直保持活跃。近年来,它更因其加载次级有效负载(如 Cobalt Strike 等入侵后框架)的能力而闻名,并且已关联到勒索软件活动。

ICEDID 通过一个多阶段过程实现,包含不同的组件。初始访问通常通过利用恶意文档或文件附件的网络钓鱼活动获得。

我们将在接下来的几节中讨论 ICEDID 的各个方面,并探讨我们在追踪 ICEDID 基础设施方面的分析技术。

  • 初始访问
  • 命令与控制
  • 持久性
  • 核心功能
  • 网络基础设施

如前言中所述,ICEDID 已经存在多年,并且功能丰富。由于该恶意软件多年来已被多次分析,因此我们将重点关注一些更有趣的功能。

初始访问

ICEDID 感染形式多种多样,并且已使用不同的技术和新颖的执行链进行调整,以避免检测并规避反恶意软件产品。在本示例中,ICEDID 通过网络钓鱼电子邮件进行投递。电子邮件包含一个嵌入 ISO 文件的 ZIP 压缩文件。ISO 文件内包含一个 Windows 快捷方式 (LNK),双击该快捷方式会执行第一阶段 ICEDID 加载程序 (DLL 文件)。

Windows 快捷方式的目标值配置为执行 **%windir%\system32\rundll32.exe olasius.dll,PluginInit**,调用 **PluginInit** 导出函数,从而启动 ICEDID 感染的第一阶段。此阶段负责解密嵌入的配置,从 C2 服务器下载 GZIP 有效负载,将加密的有效负载写入磁盘 ( **license.dat** ),并将执行权转移到下一阶段。

第一个 ICEDID 阶段首先解密存储在 DLL 中的加密配置数据块,该数据块用于保存 C2 域名和活动标识符。前 32 个字节表示 XOR 密钥;然后使用此密钥解密加密数据。

命令与控制

ICEDID 使用包含来自受感染机器的十六进制数据的 cookie 参数构建初始 HTTP 请求,用于对受害者机器进行指纹识别。无论是否存在任何先前的识别信息,此请求都将继续下载 GZIP 有效负载。

eSentire 已发布研究,详细描述了如何创建 gads、gat、ga、u 和 io cookie 参数。

以下是 cookie 参数及其关联示例值。

参数示例数据说明
__gads3000901376:1:16212:134包含活动 ID、标志、GetTickCount、正在运行的进程数
__gat10.0.19044.64操作系统版本、体系结构
__ga1.591594.1635208534.76来自 CPUID/SwitchToThread 函数的虚拟机监控程序/处理器信息
__u4445534B544F502D4A4B4738455432:6A6F656C2E68656E646572736F6E:33413945354637303742414339393534存储计算机名称、用户名和机器人 ID
__io21_3990468985_3832573211_2062024380安全标识符 (SID)
__gid006869A80704加密的 MAC 地址

下载的 GZIP 有效负载包含一个自定义结构,其中包含第二个加载程序 ( **hollow.dat** ) 和加密的 ICEDID 核心有效负载 ( **license.dat** )。这两个文件被写入磁盘,并结合使用以在内存中执行核心有效负载。

下一阶段突出了 ICEDID 在加载核心有效负载 ( **license.dat** ) 方面的一个独特元素,它使用自定义标头结构而不是传统的 PE 标头。使用下一有效负载的各个部分循环并将其放置到它们自己的虚拟内存空间中分配内存。这种方法已被充分记录,并作为一种阻碍分析的技术。

每个部分的内存保护都由 **VirtualProtect** 函数修改,以使用 **PAGE_READWRITE** 常量启用对已提交内存区域的只读或读写访问。

设置映像入口点后,ICEDID 核心有效负载将通过对rax x86 寄存器的调用加载。

持久性

ICEDID 将首先尝试使用计划任务设置持久性,如果失败,它将改为创建 Windows 注册表运行键。使用机器人 ID 和 **RDTSC** 指令,随机生成计划任务或运行键名称。使用 **taskschd.dll** 创建计划任务,配置为在用户登录时运行,并且无限期地每 1 小时触发一次。

核心功能

ICEDID 恶意软件的核心功能已被充分记录,并且在很大程度上没有改变。要了解有关核心有效负载和功能的更多信息,请查看Malpedia 页面,其中包含关于 ICEDID 的已完成研究的语料库。

也就是说,在我们分析期间,我们统计了 23 个模块,包括

  • 用于窃取凭据的中间人代理
  • 反向连接模块
  • 命令执行 (PowerShell、cmd)
  • Shellcode 注射
  • 收集
    • 注册表键数据
    • 正在运行的进程
    • 凭据
    • 浏览器 cookie
    • 系统信息(网络、防病毒、主机枚举)
  • 搜索和读取文件
  • 用户桌面的目录/文件列表

ICEDID 配置提取器

Elastic 安全实验室已发布一个根据 Apache 2.0 许可证发布的开源工具,该工具允许从 ICEDID 样本中提取配置。该工具可以从这里下载。

TLS 证书固定

之前对 ICEDID 恶意软件家族的研究强调了活动创建其自签名 TLS 证书的重复方式。特别值得注意的是,这种创建 TLS 证书的技术大约 18 个月内没有更新。虽然具有推测性,但这可能反映出该 C2 基础设施没有被威胁数据提供商广泛跟踪。这使 ICEDID 能够专注于更新其活动中更易变的元素(文件哈希、C2 域名和 IP 地址)。

Check Point 团队发布了关于使用 ICEDID 的 TLS 证书固定功能跟踪 ICEDID 基础设施的深入且清晰的研究。此外,Check Point 发布了一个脚本,该脚本接收 IP 地址和端口,并将可疑的 TLS 序列号与 ICEDID 恶意软件计算出的值进行验证,以确认该 IP 地址当前是否正在使用 ICEDID TLS 证书。

我们提供了一个包装器,它结合了来自 Censys 的互联网扫描数据和来自 Check Point 脚本的 ICEDID C2 基础设施确认。它可以从 这里下载。

数据集

正如 Check Point 所报道的,TLS 证书信息使用相同的颁发者和主体可分辨名称来验证 C2 服务器,然后再发送任何数据。

为了构建我们的数据集,我们使用了 Censys CLI 工具 来收集证书数据。我们需要对 Check Point 研究中的查询进行一些小的调整,但结果相似。

censys search 'services.tls.certificates.leaf_data.subject_dn:"CN=localhost, C=AU, ST=Some-State, O=Internet Widgits Pty Ltd" and services.tls.certificates.leaf_data.issuer_dn:"CN=localhost, C=AU, ST=Some-State, O=Internet Widgits Pty Ltd" and services.port=443'

[
  {
    "ip": "103.208.85.237",
    "services": [
      {
        "port": 22,
        "service_name": "SSH",
        "transport_protocol": "TCP"
      },
      {
        "port": 80,
        "service_name": "HTTP",
        "transport_protocol": "TCP"
      },
      {
        "port": 443,
        "service_name": "HTTP",
        "certificate": "c5e7d92ba63be7fb2c44caa92458beef7047d7f987aaab3bdc41161b84ea2850",
        "transport_protocol": "TCP"
      }
    ],
    "location": {
      "continent": "Oceania",
      "country": "New Zealand",
      "country_code": "NZ",

…truncated…

这为我们提供了 113 个 IP 地址,这些地址使用我们可以开始归因于 ICEDID 活动的证书。

JARM / JA3S

在查看来自 Censys 的数据时,我们还确定了其他一些有助于跟踪 TLS 通信的字段:JARMJA3S,这两个都是来自 Salesforce 团队的 TLS 指纹工具。

从高级别来看,JARM 通过主动收集 TLS 服务器 Hello 响应的特定元素来为 TLS 服务器生成指纹。JA3S被动地从 TLS 服务器 Hello 消息中收集值。JARM 和 JA3S 分别以 62 个字符或 32 个字符的指纹表示。

JARM 和 JA3S 添加了额外的數據点,从而提高了我们连接 ICEDID C2 基础设施的信心。在我们的研究中,我们确定了 **2ad2ad16d2ad2ad22c2ad2ad2ad2adc110bab2c0a19e5d4e587c17ce497b15** 作为 JARM 指纹,并确定了 **e35df3e00ca4ef31d42b34bebaa2f86e** 作为 JA3S 指纹。

需要注意的是,JARM 和 JA3S 通常不够独特,无法单独确认主机。例如,在 Censys 数据集中,JARM 指纹识别了超过 15k 个主机,JA3S 指纹识别了超过 330 万个主机。同时查看 JARM 和 JA3S 值仍然大约有 8k 个主机。这些只是通往答案的旅程中的数据点,而不是答案本身。

ICEDID 植入防御

在 ICEDID 与其 C2 服务器通信之前,它会通过将证书序列号与证书公钥的哈希值进行比较来执行 TLS 证书检查。由于证书序列号都应该是唯一的,因此 ICEDID 使用自签名证书和预期证书序列号作为验证 TLS 证书的一种方式。如果公钥和序列号的哈希值不匹配,则不会继续与 C2 服务器通信。

我们使用了 Check Point Python 脚本(它会为每个传递的 IP 地址返回 **true** 或 **false** 结果)来执行额外的检查,以提高我们对 IP 地址是否属于 ICEDID C2 基础设施而非仅仅是具有相同 ICEDID TLS 证书主体和颁发者信息的巧合的信心。**true** 结果表示具有匹配的 ICEDID 指纹,而 **false** 结果则表示没有。这导致 103 个 IP 被确认具有 ICEDID TLS 证书,10 个没有(截至 2022 年 10 月 14 日)。

导入 Elasticsearch

现在我们有了一种基于 TLS 证书元素收集 IP 的方法,以及一种添加额外上下文以帮助确认的方法;我们可以将逻辑封装在 Bash 脚本中,以此来自动化此过程并解析数据以在 Elasticsearch 中进行分析。

#!/bin/bash -eu

set -o pipefail

SEARCH='services.tls.certificates.leaf_data.subject_dn:"CN=localhost, C=AU, ST=Some-State, O=Internet Widgits Pty Ltd" and services.tls.certificates.leaf_data.issuer_dn:"CN=localhost, C=AU, ST=Some-State, O=Internet Widgits Pty Ltd" and services.port=443'

while read -r line; do
    _ts=$(date -u +%FT%TZ)
    _ip=$(echo ${line} | base64 -d | jq '.ip' -r)
    _port=$(echo ${line} | base64 -d | jq '.port' -r)
    _view=$(censys view "${_ip}" | jq -c)
    _is_icedid=$(python3 -c "import icedid_checker; print(icedid_checker.test_is_icedid_c2('${_ip}','${_port}'))")

    echo "${_view}" | jq -S --arg is_icedid "${_is_icedid}" --arg timestamp "${_ts}" '. + {"@timestamp": $timestamp, "threat": {"software": {"icedid": {"present": $is_icedid}}}}'
done < <(censys search --pages=-1 "${SEARCH}" | jq '.[] | {"ip": .ip, "port": (.services[] | select(.certificate?).port)} | @base64' -r) | tee icedid_infrastructure.ndjson

这会将数据输出为名为 **icedid_infrastructure.ndjson** 的 NDJSON 文档,我们可以将其上传到 Elasticsearch 中。

在上图中,我们可以看到有些主机具有已识别的 JARM 指纹、已识别的 TLS 颁发者和主体元素,但未通过 Check Point 验证检查。此外,这两台主机中的一台具有不同的 JA3S 指纹。这突出了多个数据源组合在信息置信度评分方面的价值。

我们也 提供此脚本 供其他人使用。

观察到的对手战术和技术

Elastic 使用 MITRE ATT&CK 框架来记录高级持续威胁针对企业网络使用的常见战术、技术和程序。

如上所述,ICEDID 已经被广泛分析,因此我们在下面列出了我们观察到的并包含在本研究出版物中的战术和技术。如果您对 MITRE ATT&CK 的全部战术和技术感兴趣,可以查看 MITRE 关于 ICEDID 的 页面

战术

战术代表技术或子技术的“为什么”。它是对手的战术目标:执行操作的原因。

技术 / 子技术

技术和子技术代表对手如何通过执行操作来实现战术目标。

检测和预防

检测逻辑

预防措施

  • 恶意行为检测警报:命令外壳活动
  • 内存威胁检测警报:Shellcode 注入
  • 恶意行为检测警报:Rundll32 或 Regsvr32 加载的异常 DLL 扩展
  • 恶意行为检测警报:可疑的 Windows 脚本解释器子进程
  • 恶意行为检测警报:带有异常参数的 RunDLL32
  • 恶意行为检测警报:来自归档文件的 Windows 脚本执行

YARA

Elastic Security 创建了 YARA 规则 来识别此活动。下面是一个 YARA 规则,专门用于识别 ICEDID 使用的 TLS 证书固定功能。

rule Windows_Trojan_IcedID_cert_pinning {
    meta:
        author = "Elastic Security"
        creation_date = "2022-10-17"
        last_modified = "2022-10-17"
        threat_name = "Windows.Trojan.IcedID"
        arch_context = "x86"
        license = "Elastic License v2"
        os = "windows"
    strings:
		$cert_pinning = { 74 ?? 8B 50 ?? E8 ?? ?? ?? ?? 48 8B 4C 24 ?? 0F BA F0 ?? 48 8B 51 ?? 48 8B 4A ?? 39 01 74 ?? 35 14 24 4A 38 39 01 74 ?? }
    condition:
        $cert_pinning
}

参考文献

以下内容在上述研究中被引用

指标

在本研究中观察到的指标如下所示。所有工件(包括通过 TLS 证书固定发现的工件)也都 可供下载,以 ECS 和 STIX 格式打包在压缩包中。

指标类型说明
db91742b64c866df2fc7445a4879ec5fc256319e234b1ac5a25589455b2d9e32SHA256ICEDID 恶意软件
yolneanz[.]com域名ICEDID C2 域名
51.89.190[.]220ipv4-addrICEDID C2 IP 地址