原创奇安信X实验室 2025-06-11 16:39 北京

背景

目前已有境外黑客组织利用ComfyUI漏洞对我网络资产实施网络攻击，伺机窃取重要敏感数据 -- 来自国家网络安全通报中心

2025年5月27日，国家网络安全通报中心发布预警，指出ComfyUI存在数个高危漏洞，且已被黑客组织利用，要求企业采取防护措施，避免网络与数据安全风险。显然，随着私有化部署AI模型的浪潮席卷各行各业，作为大模型图像生成领域的热门框架，ComfyUI在获得广泛应用的同时，也不可避免地成为了黑客攻击的重点目标。本文将介绍奇安信XLab视野中的攻击活动，并详细分析这些攻击活动的具体特征和危害方式。

让我们把时钟拨回到2025年3月17日，

Xlab大网威胁感知系统

检测到IP 185.189.149.151通过ComfyUI漏洞传播多个伪装成配置文件的VT 低检测ELF可执行程序（如config.json，tmux.conf，vim.json等）经过分析，我们确认这几个文件属于同一个后门木马，基于它们具有窃取AI敏感数据的能力，我们从扒手（pickpocket）一词获得灵感，将它命名为AI扒手，Pickai。

Pickai是一个由C++编写的轻量级后门程序，主要功能包括远程命令执行和反弹shell。麻雀虽小，但五内脏俱全，Pickai具有较强的隐蔽性，健壮性以及持久化能力。在主机行为层面，它支持反调试、进程伪装和多种持久化机制；在网络通信层面，虽然未采用加密算法，但内置了多个C2（命令与控制）服务器作为冗余备份，定时检测C2可用性，自动切换以维持控制链路的稳定。

在逆向分析过程中，我们发现Pickai的一个C2域名 h67t48ehfth8e.com 处于未注册状态后，立即进行了抢注。通过接管该域名，我们成功获取了部分威胁视野，数据显示全球共有695台服务器被感染。Pickai的作者发现这一情况后，马上更新样本，投入一个有效期长达5年的C2 域名 historyandresearch.com，表现出一种针锋相对的对抗姿态。

另外值得注意的是Pickai 的恶意样本托管在电商赋能平台 Rubick.ai 的官方网站。Rubick是一家AI电子商务公司，它的业务覆盖美国、印度、新加坡、中东等国际市场。从官网和其他的公开信息来看，Rubick已为200多家领先的电子商务品牌提供服务，部分知名客户包括：

亚马逊（Amazon）：利用 Rubick.ai 的目录管理服务优化其产品数据。

The Luxury Closet（阿联酋）：奢侈品电商，使用其 AI 工具进行图像编辑和产品属性提取

Hudson Bay：北美零售商，使用其 PIM 和营销工具提升产品展示效率。

Myntra：印度领先的时尚电商平台，依赖 Rubick.ai 的目录管理服务处理超过 700 万个 SKU

Rubick.ai作为众多客户的 upstream 服务提供商，它被黑客入侵就意味着它的产品、服务都有可能被值入恶意代码，带来严重的

供应链攻击

风险。再考虑到当前安全厂商对 Pickai 样本的检测多为泛型（Generic）结果，且大量 C2 服务器尚未被有效标记。我们决定撰写本文向社区分享这一发现，共同维护网络安全。

时间线

2025年2月28日，Pickai的早期版本从香港上传到VT，使用的C2为

195.43.6.252

。

2025年3月17日，XLab首次捕获通过ComfyUI漏洞传播Pickai的Payload。

2025年5月3日，XLab向Rubick.ai通告被入侵，遗憾的是该公司并未回应。

2025年5月26日，XLab监测到Pickai的另一个下载服务器

78.47.151.49

。

感染分布与基础设施

2025年3月17日，我们对C2 h67t48ehfth8e.com进行抢注，依托于该域名，我们获得了Pickai后门的部分感染视野。从数据来看，全球有近700台设备被感染，主要分布在德国，美国和中国。

Pickai对于C2的访问是有先后顺序的，其中h67t48ehfth8e的优先级最低。4月13日以及5月5日两天出现Spike，峰值超过400。我们认为，该数字体现了Pickai真实的日活。Spike的原因是在那两天其余C2出现故障，从而使得h67t48ehfth8e有机会一窥全貌。

Pickai样本更新后，引入一个有效期长达5年的C2

historyandresearch.com

,该域名的构词，以及没有开启DNS解析的行为，都像是对我们抢注行为的回应。我们推测攻击者的心理活动是这样的：

"XLab你们不是挺能抢注域名嘛，来，我整个5年有效期的C2，再抢过去给我看看？！哈哈，我就是要挑衅你们，把你们气个半死却拿我没办法，爽！"

对此，我们只想说，“不能接管这个域名，我们可以曝光其他的C2呀！”。目前Pickai的C2服务器虽然检测率接近零，但相信安全社区很快就会让它的作者明白：恶意软件的生存周期，从来都是由防御者书写的。

样本分析

我们一共捕获了7个Pickai样本，本文以5月26日最新的样本为主要分析对象，它的基本信息如下所示：

MD5:8680f76a9faaa7f62967da8a66f5a59c

MAGIC:ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.2.0, stripped

Pickai的功能比较简单，当它运行时，首先对加密的字符串进行解密，包括C2，持久化脚本等各种敏感的配置信息，然后通过检测进程的TracerPid字段进行反调试，使用pid文件确保单一实例运行，调用prctl函数对进程名进行修改进。接着根据当前用户的不同权限，通过init.d或systemd实现持久化，最后和C2建立通信，等待执行C2下发的指令。

下文将从主机行为与网络通信两个维度对Pickai后门进行分析，重点关注字符串解密、持久化机制和网络协议等关键技术特征。

Part 1: 解密字串

Pickai的大部分敏感字符串加密存储在rodata段，加密方法为单字节与0xAF进行异或。因此密文有一个明显的特征，即以0xAF结尾。

为了逆向分析的方便，可以使用以下idapython代码进行解密，只需要确定

密文的开始与结尾

即可。

startAddr=0x000000000000D028
endAddr=0x000000000000DBD8
buf=ida_bytes.get_bytes(startAddr,endAddr-startAddr)
items=buf.replace(b'\x00',b'').split(b"\xaf")
for item in items:
    plaintxt=bytearray()
    ciphertxt= ' '.join(f'{byte:02X}' for byte in item)
    addr=idc.find_binary(startAddr,idaapi.SEARCH_DOWN,ciphertxt)

    for i in item:
        plaintxt.append(i^0xaf)
    print(f"0x{addr:x}, has {len(plaintxt)} bytes ----> {plaintxt}")
    plaintxt.append(0)
    ida_bytes.patch_bytes(addr,bytes(plaintxt))
    idc.create_strlit(addr,addr+len(plaintxt))