警惕AI扒手:Pickai后门正通过ComfyUI漏洞传播

背景

" 目前已有境外黑客组织利用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。
    pickai.tmux.png

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

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

感染分布与基础设施

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

pickai_stat.png

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

pickai_ips.png

Pickai样本更新后,引入一个有效期长达5年的C2 historyandresearch.com,该域名的构词,以及没有开启DNS解析的行为,都像是对我们抢注行为的回应。我们推测攻击者的心理活动是这样的:

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

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

pickai_vt.png

样本分析

我们一共捕获了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结尾。

pickai_0xaf.png

为了逆向分析的方便,可以使用以下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))

效果如下所示,解密出的明文中包括C2,进程伪装,持久化等功能相关的信息。

pickai_dec.png

Part 2: 主机行为

Pickai在主机行为方面,支持反调试,单一实例,进程伪装,持久化等特性。它们的技术实现上并无特别的“脑洞”,进程伪装和持久化稍有特色,它们都体现了一个“多”的特点。

0x1: 进程伪装

进程伪装的“多”,体现在伪装的进程名上。Pickai会在20个进程名中随机选择一个,使用prctl函数对自身进程名进行修改。

pickai_fakeproc.png

伪装进程名的详细信息如下:

[cpuhp/1] [ipv6_addrconf] [kblockd] [kcompactd0]
[kdevtmpfs] [khugepaged] [khungtaskd] [kintegrityd]
[kmpath_handlerd] [kmpath_rdacd] [kmpathd] [kthrotld]
[kworker/0:0-events] [kworker/0:0H-events_highpri] [kworker/0:1-cgwb_release] [kworker/0:1H-kblockd]
[kworker/10:0H-events_highpri] [kworker/10:1H-kblockd] [kworker/10:2-events] [kworker/11:0-events]

0x2: 持久化

持久化的“多”,体现在持久化服务数量上:root用户10个,普通用户5个。

pickai_persistance.png

当前用户权限为root时,Pickai首先会将自身复制到5个不同的路径,并同步它们的“最后修改时间”至“/bin/sh”文件的时间戳,然后创建服务,利用init.d & systemd 俩种机制实现持久化。

pickai_root.png

以下为Pickai副本所在的路径,以及它们对应的持久化服务。使用init.d机制时,这些服务位于/etc/init.d/目录,而systemd机制,这些服务则位于/usr/lib/systemd/system/或/lib/systemd/system/。

Path ServiceName
/usr/bin/auditlogd auditlogd
/usr/sbin/hwstats hwstats
/sbin/dmesglog dmesglog
/var/lib/autoupd autoupd
/var/run/healthmon healthmon

很明显,Pickai试图仿冒正常系统服务,蒙混过关。实际创建的auditlogd持久化脚本如下所示:

pickai_auditlogd.png

另外值得一提的是,Pickai在自我复制过程中,会在文件尾部追加随机数据。这种技术手段很明显是在规避基于文件哈希值的检测机制。

pickai_append.png

可以看出5个Pickai副本的MD5完全不一样:

pickai_md5s.png

当用户权限不是root时,Pickai使用systemd机制实现持久化,整个过程与root权限相似,只不过副本路径以及服务名称有所不同。这些服务位于$HOME/.config/systemd/user/

Path ServiceName
$HOME/.local/share/nano/nano nano
$HOME/.vim/vim vim
$HOME/.sshd/config/ssh.config ssh.config
$HOME/.cache/mail/mail-sync mail-sync
$HOME/.gnome/config/gnome-X11 gnome-X11

Pickai正是通过这种冗余的持久化机制,在被感染设备上实现多个分身,只要一处没有清理干净,它就能卷土重来

Part 3: 网络通信

Pickai通过一个永真的循环进行网络通信,它的通信机制采用三级定时策略:每43200秒(12小时)从6个硬编码C2中轮换活跃节点,每1200秒周期性上报设备信息,每120秒向C2请求指令。

pickai_time.png

0x1: 请求指令报文

长度1024字节,前7字节为“LISTEN|”,其余部分0x00填充。支持EXECUTEREVERSE俩个指令,它们分别对应执行系统命令和反弹shell俩个功能。
pickai_cmd.png

0x2: 上报设备信息报文

长度1024字节,前7字节为“UPDATE|”,其后紧跟着3部分元数据,未使用的空间使用0x00填充

  • 系统指纹(uname -a)
  • 特权状态(当前用户是否为root)
  • 是否为docker(检测1号进程是否为init或systemd)

pickai_update.png

0x3: C2验活报文

样本中硬编码了6个C2,Bot以先后顺序为优先级,依次向这些C2发送验活请求,直至收到首个活跃C2的响应。这种设计使得高优先级C2在正常通信时掩盖低优先级C2的存在,在一定程度上能够对抗基于沙箱流量进行IOC生产的系统。

pickai_c2.png

验活报文长度7字节,固定为“STATUS|”,当C2回复LISTENING时,表示该C2处于活跃状态。
pickai_checkalive.png

0x4: 跟踪到的指令

我们在XLab指令跟踪系统中实现了Pickai的协议,只在6月6日接收2条指令,用于开启反弹shell。由于尚未对REVERSE、EXECUTE等后续攻击指令进行模拟,攻击者在成功建立shell会话后的具体攻击意图暂无法完整溯源。

pickai_reverse.png

总结

Pickai的冗余持久化机制使其具备类似顽固木马的特性,即使仅残留一处未被清理,就能触发再生。网络管理员可基于前文所述的Pickai主机行为特征进行深度排查,确保其植入的5个副本被彻底清除,避免残留导致二次感染。

这是我们当前掌握的关于Pickai的基本情报,诚邀具有独特视角的同行企业及受此后门木马影响的网络管理员通过X平台向提供进一步的线索。同时,也欢迎对我们研究感兴趣的读者与我们联系,获取更多详细信息&内幕花絮。

IOC

MD5

f9c955a27207a1be327a1f7ed8bcdcaa *old_version
ebd188be8e7ad72219fd9a227881dd8d *old_version
0641a20bde5bc620f115975c15d0cf40 *vim
fe9896eca398167f5d0304e555d170eb *config.json
7bc08ae32a2e0c9e07c98c2ade45c7f0 *tmux.conf
c587e4596fce1de62d132f46ca1f03de *vim.json
8680f76a9faaa7f62967da8a66f5a59c *x64

Downloader URL

http://78.47.151.49:8878/wp-content/x64
https://rubick.ai/wp-content/tmux.conf
https://rubick.ai/wp-content/vim.json
https://rubick.ai/wp-content/config.json

C2

80.75.169.227	Egypt|Al Qahirah|Cairo	AS36992|ETISALAT MISR
195.43.6.252	Egypt|Al Qahirah|Cairo	AS6879|Egyptian National Scientific & Technical Information Network
154.68.72.34	Rwanda|Ville de Kigali|Kigali	AS37654|Rwanda Ministry of Education
185.189.149.151	Switzerland|Zug|Baar	AS51395|Datasource AG
102.214.30.199	Tanzania|None|None	AS0|
38.180.207.9	United States|None|None	AS174|Cogent Communications  

historyandresearch.com