keyHunter：一场泄露了自身工具包的 LLM 代理密钥窃取行动

TLP:CLEAR。已批准公开发布。下文几乎全部内容都是操作者自己的材料，是在其智能体于自己的主机上执行了 Kinryū Labs 诱饵的工具调用、并把输出回传时被恢复出来的。指标均已做无害化（defang）处理，也就是把攻击者地址写成无法被误点或误解析的形式。扫描目标、操作者标记出的一台第三方主机，以及他们完整的 FOFA API 密钥，均予以保留不公开。

摘要

• 27,173经 FOFA 扫描的候选主机
• 194列出了模型的主机
• 17导出的 API 密钥
• 62026 年 CVE（按文件名计）

一名讲中文的操作者跨八个国家扫描了 27,173 台主机，只为一个目标：背后挂着有效密钥、暴露在公网的 AI 代理面板。所谓 AI 代理面板，是各团队摆在自家应用与付费模型服务商之间的软件，好让一套服务商密钥被共享使用，例如 LiteLLM、One-API 及其分支 New-API、Sub2API 与 Chat2API。把这样一台面板不设密码地丢在公网上，它背后的一切算力就都能被陌生人拿去消费。操作者通过 FOFA 找到它们（FOFA 是一个建立在持续全网扫描之上的搜索引擎，相当于中国版的 Shodan），核对哪些面板仍有应答，然后导出密钥。

这些数字是操作者自己的，取自其结果文件，而非我们的估算。在这 27,173 台主机中，194 台会列出模型，17 个密钥进入了他们的导出文件。美国那一轮是最清晰的单一案例：投入 10,447 个目标，产出 64 条模型列表，命中率 0.61%，而其原因，他们自己的智能体也能说清。真正暴露在公网、又确实可调用的 LiteLLM 很罕见，而且他们扫描器里一个 URL 拼接的缺陷把存活主机误判成了死主机。

关于命名

我们将其追踪代号定为 keyHunter，取自操作者自己的项目目录 /root/keyHunter-skill/。

他们所驱动的智能体框架叫 Hermes，而 Hermes 是 Nous Research 出品的一个真实开源项目。用它来给这个行为体命名，等于让一款正当工具替别人的所作所为背锅，所以我们不这么做。机器上的第二个智能体框架 OpenClaw 同理。两者都是操作者自行安装、再指向他人基础设施的普通软件。

操作者

操作者从三台主机开展工作，全部位于中国的云上，工作在其间分工进行。阿里云（AS37963）上的 39.98.82[.]200 运行智能体网关，我们所见的大部分侦察也出自它。腾讯云（AS45090）上的 101.43.41[.]72 是一台中继，在 8087 端口上提供一个 OpenAI 兼容端点，供智能体调用以获取模型算力。二者共用 JA4H 指纹 po11nn070000_ebbca96fac43（该指纹刻画的是一个客户端如何组装其 HTTP 请求，并能在换地址后依然保持不变），还共用定制的 Hermes-Agent/0.18.0 与 Hermes-Panel/1.0 user-agent，以及同一个共享的会话标识。综合来看，这些把两个节点都归到了同一个操作者名下。这个指纹并非一次性抓取的产物：位于不同地区的两台独立传感器在 8 月 16 日至 20 日之间各自独立记录到了它，两次都出现在同一场 FOFA 驱动的扫描中。

扫描又发生在另一处。他们从阿里云主机出发，通过一个本地转发抵达一台华为云虚拟机：

ssh -o ServerAliveInterval=20 -i /root/.ssh/hw_vm_key -p 8888 [email protected] \
    'cd /home/developer && /home/developer/.venv-us30/bin/python litellm_scan_us_30d_optimized.py'

那台机器已运行了四天零九小时，配有 7.5 GB 内存和四个核心，跑着扫描工作进程。把动静很大的扫描与智能体前端分开是一个刻意的选择，而 hw_vm_key 这个名字表明操作者把它当作那台华为主机看待。

控制走的是微信。网关服务自我描述为 “Hermes Agent Gateway, Messaging Platform Integration”，操作者通过在一个微信会话里与智能体聊天来给它派活。智能体的长期记忆就是那段对话：它靠检索自己的聊天历史来回想自己正在做什么。第二个框架也呈现出同样的模式，会话名为 openclaw-weixin。一款面向消费者的即时通讯应用构成了一条廉价的控制信道：流量默认加密，并与其他每一个微信用户一道汇往腾讯，因此它不会触发任何针对命令与控制信标而调校的检测。

支撑这一切的推理引擎是 github_copilot/gpt-5.6-sol，一款通过中继访问的商用编码助手。他们的配置里还接入了另外几家服务商的可选密钥。进攻代码是自研的 Python；其下的推理模型、智能体框架与微信控制信道，则全是现成的消费级产品。

流水线

他们的主技能用一句话描述了整场行动：“Discover, scan, verify, and archive publicly exposed AI API proxy panels (LiteLLM, Sub2API, New-API, One-API) using FOFA + keyHunter + custom verification scripts.”

FOFA search, per country
  -> dedupe and normalise targets
  -> light HTTP fingerprint
  -> /v1/models listing
  -> real chat completion per model
  -> honeypot classification
  -> weak-credential panel login, key extraction
  -> export keys and accounts, archive

发现环节是一条 FOFA 查询，按国家逐一重复：

(title="LiteLLM" || body="LiteLLM") && country="{cc}" && org!="AMAZON-AES"

真正关键的是那条排除 AWS 的子句。操作者在看向任何一台主机之前，就先把亚马逊从每一次扫描中过滤掉。在你的边界上封禁 Shodan 与 Censys 的地址段，对一条建立在别人扫描数据之上的流水线毫无用处。

他们为每个国家单独保留脚本：美国用 litellm_scan_hw.py，还有 litellm_scan_gb_hw.py、litellm_scan_it_hw.py、一个自带虚拟环境的 litellm_scan_us_30d_optimized.py，以及 keyHunter-skill/ 下另一组覆盖澳大利亚、巴西、加拿大、法国、印度、荷兰与新加坡的脚本。结果文件涉及十四个国家。并发为 48 个轻量工作进程和 12 个深度工作进程，针对 FOFA 的 429 响应有限速退避，端点去重以协议、主机和端口为键。

FOFA API 密钥被硬编码在扫描器源码里，我们也正因此拿到了它。它请求的是位于 hamal.cc[.]cd 的一个非官方 FOFA 镜像，并经由一个本地 Squid 代理出网。

一次扫描到底返回了什么

国家	FOFA 目标数	列出模型数	命中率
美国	10,447	64	0.61%
中国	6,329	83	1.31%
韩国	1,772	10	0.56%
英国	1,422	18	1.27%
意大利	1,130	9	0.80%
澳大利亚、印度、巴西	6,073	10（其中 4 个已验证）	0.16%

一次被捕获的运行：从 FOFA 得到 2,255 条原始记录，去重后 1,130 个唯一端点，9 个站点列出了模型，8 个通过验证；在请求层面，41 次模型成功对 8 次失败。

他们收集的 FOFA 标题普查说明了这批暴露资产的样貌。LiteLLM API - Swagger UI 返回 7,630 条结果。OmniRoute 返回 171 条，SillyTavern 170 条，LiteLLM Dashboard 156 条，Claude Code Hub 131 条，Aivar AI Gateway 11 条。这片攻击面大多是同一款产品，而该产品暴露的实例又大多是那张自动生成的 API 文档页面。

我们评估，管道最末端的产出在绝对量上很低。litellm_extracted_keys.json 记录了 43 个实例、横跨 23 个模型的 3 个提取出的密钥。exported_keys.json 里则有 17 个。扫了数万台主机只换来十七个密钥，这要么是投入产出比很差，要么恰恰印证了：因为活是智能体在干，所以这份投入很廉价。

反欺骗：他们主动猎杀蜜罐

工程能力在一个文件里体现得最清楚：litellm_verifier.py。

它有 10 KB，附带一套单元测试。它向面板所宣称的每一个模型发送一次真实的、极简的对话补全，只有在收到符合 OpenAI 结构的 choices/message/content 响应，或一次带结束标记的合法流式回复时，才记为成功。用他们自己的规则、自己的话说：单凭一次 /models 成功永远不算数。测试名把这一点编码了进去，其中就有一个叫 test_models_listing_alone_is_not_success。有人写了一个回归测试，来阻止自己的工具在一个被窃密钥的问题上自欺欺人。

某一次运行的判定计数：

verdict_counts: honeypot_or_unusable 20 · trusted_pass 5 · unavailable 16
formatted_false_success_model_hits 29
non_chinese_evidence_count 13
total_questions 205

formatted_false_success 指的是一条套路化或原样回显的回答，一个幼稚的诱饵正是这么应答的。non_chinese_evidence 则给“某个模型的行为是否像它所自称的那家厂商”打分。他们还会跑一套蜜罐五题测试，并在被捕获的时间窗内用它把一台位于 AWS 伦敦地址段的主机标记为蜜罐。我们对该地址不予公开，因为它是别人的传感器，点名它就等于烧掉它。

一个购买赃算力的买家如今会预设这个端点可能是陷阱，并主动去测试它，这让低交互诱饵在这片攻击面上几近无用。而能反过来抓住他们的对策，是把同一套测试反向来做：任何一个客户端，若无视 API 参数、要求你的网关证明它真正在运行的是哪个模型，那就是在验货。

漏洞利用武器库：全是 n-day

他们那些漏洞利用结果文件的内容从未到达我们手中。文件名倒是到了，而它们针对的都是有公开公告的开源产品，因此这些利用手法可从公告中还原出来。

其主机上的结果文件	CVE	漏洞	依据
litellm_host_header_bypass_results.json (568 KB)	CVE-2026-49468	LiteLLM 经由 Host 头注入的认证绕过，CVSS 9.8，影响 1.84.0 之前版本。使认证与路由失步，从而可未经认证访问 /key/generate 与 /user/new	已佐证：同样的管理面调用被投向我们的诱饵，且他们打出了 CVE-2026-49468-Scanner 这个 user-agent
litellm_sqli_apikey_results.json (517 KB)、litellm_sqli_models.json	CVE-2026-42208	LiteLLM 认证路径中的预认证 SQL 注入	已佐证：他们朝我们的密钥字段打了十九次 ' OR '1'='1
litellm_rce_exploit.json、litellm_mcp_rce_results.json	CVE-2026-42271	LiteLLM 命令注入与远程代码执行，CVSS 8.7，收录于 CISA 已知被利用漏洞清单，影响 1.74.2 至 1.83.6，含一个 MCP 注入向量	据文件名与产品推断
sub2api_cve_exploit.json 及后续三个阶段	CVE-2026-27812	Sub2API 经由受信任的 Host 与 Forwarded 头进行的密码重置投毒，导致账户接管。已在野利用，影响 0.1.85 之前版本	推断
newapi_stripe_bypass_results.json、newapi_stripe_exploited.json、newapi_quota_overflow_results.json	CVE-2026-41432	New-API 经由空密钥造成的 Stripe webhook 签名绕过，无需付款即可获得无限配额，影响 0.12.10 之前版本	推断
newapi_user_token_leak_results.json、oneapi_user_token_leak_results.json、newapi_ssrf_bypass_results.json	CVE-2026-30886	New-API 在视频代理端点上的不安全直接对象引用与认证绕过，可泄露其他用户的内容，并让攻击者在上游花掉受害者的凭据	推断
litellm_ssti_prompts_results.json	无单一公告	针对 prompt 与 template 端点的 Jinja2 服务端模板注入	推断

没有任何文件的内容到达我们手中；每一行都建立在文件名之上。其中两项我们独立地在自己的传感器上观察到了对应技术的到来，即 Host 头绕过与认证 SQL 注入，这佐证的是技术本身，而非那个文件。另外四项则建立在文件名加上产品已知公告之上，并已如此标注。

六者贯穿始终的模式是一样的。每一份公告都出自 2026 年，其中数份还来自同一季度，无一属于原创研究。keyHunter 在开源 LLM 代理生态中每有新披露的高危缺陷落地，便立刻将其产业化。那是一个很短的窗口期，而这类软件往往由某个开发者装好后便再无人过问。

意图：参赛叙事对阵结果目录

操作者对自己的智能体把这件事描述成一个参赛项目。在恢复出的聊天里，这套词汇是一以贯之的：比赛项目、评委、答辩材料，一个 contest-kit 目录，以及按第一轮、第二轮组织的工作。

当被问及作业范围时，操作者明确表示目标是默认凭据，原话如下：

llm 的主要就是那几个默认密码为主流，用自己的 sk 那种没办法抓到啊

这是操作者的原话。

智能体表示同意，并确认认证尝试仅限三种情形：无认证、sk-test、以及 sk-1234，最后这个正是 LiteLLM 自家快速上手文档所用的密钥。

接着是 /root/keyHunter-skill/results/。它的清单里，文件名点出了远程代码执行、SQL 注入、模板注入、服务端请求伪造、针对 Sub2API 的会话劫持、凭据喷洒、用户令牌泄露、配额溢出，以及两个用于 Stripe webhook 绕过的文件，其中一个是 newapi_stripe_exploited.json。我们有这些文件名，部分还有大小：Stripe 绕过的结果多达 2.4 MB，不过其内容从未到达我们手中。站得住脚的表述是：操作者针对 New-API 构建并运行了无限配额的付款绕过工具，而 CVE-2026-41432 正是这一类的真实漏洞。那 2.4 MB 的记录究竟是已完成的欺诈性充值，还是仅仅是尝试，我们看不到。文件名里的 _exploited 是操作者自己的用词；我们并未读取那些记录。

两种解读我们都暂且保留。比赛可能是真的，而漏洞利用是另一条工作线，操作者不会拿它去和一个会留日志的智能体讨论；也可能比赛只是一场盗窃行动的幌子。我们评估，这一区分对防御方而言无关紧要：无论按哪一种解读，其能力，以及一台暴露面板所面临的风险，都是完全相同的。

手法短板：操作者自己的智能体审计了这套工具

恢复出的聊天里最有价值的一段是一次代码审查。操作者问自己的智能体，扫描命中率为什么这么低，智能体便把扫描器逐行过了一遍。

智能体的回答，浓缩成防御方能用得上的部分：扫描器会给一个往往已自带协议的 FOFA host 字段再前置一个协议，生成形如 https://https://<target> 的 URL，于是存活主机被记成了死主机。线程池按创建顺序而非完成顺序收集结果，因此一个慢请求就会把排在它后面的一切都堵住。在一台四核机器上设 CONCURRENCY=200，是在自己制造超时。按 IP 去重会丢掉同一地址上其他有效的端口。写死 temperature 会把一个兼容性报错误读为失败。

谈到他们的蜜罐检测时，智能体很直白：它主要靠回复是否完全相同、或短于五个字符来判断，这会误杀正常模型，也会漏掉做得好的诱饵。而且尽管操作者要求它识别非中文的应答方，代码里却根本没有任何语言检测逻辑。

它还指出了他们的安全卫生问题：FOFA 密钥硬编码在脚本里，绝对路径写成了 /root、而实际用户却是 /home/developer，except: pass 吞掉了每一个失败原因，每个国家一份单独的脚本副本，以及那些既无访问控制也无脱敏、却存着目标与认证方式的结果文件。

最后这一点重新框定了整个漏斗。0.61% 的美国命中率，衡量的是透过一个带已知 bug 的扫描器所看到的暴露程度，因此真实的 LiteLLM 暴露率要高于操作者自己的结果所显示的。而如今他们手里有一个会不断修掉这些 bug 的智能体。

变现基础设施

同一台主机上还跑着他们自己的一个 New-API 实例：Docker 中的 calciumion/new-api:latest，发布在 8901 端口，数据以 bind mount 挂在扫描结果旁边。围绕它的还有 newapi_watchdog.py、一个渠道备份文件，以及整套东西的一份打包副本。

New-API 是一个聚合面板。它把一堆上游服务商密钥收进来，再以一个带有自家用户账户与配额的 API 对外呈现。把它架设在一条密钥收割流水线旁边，用意显而易见：收割来的密钥成为面板里的渠道，而面板则成为可供出售的访问权。我们没有观察到转售，也不作此断言；但支撑它的管路已经装好并在运行。

基于 sub2api 与 new-api 模板搭建的类似免费路由器，已有数百个在流通，而 keyHunter 只是这个生态中的一场行动。

集群关联

客户端指纹把这两台主机与另一批松散的、在同一片攻击面上活动的主机联系了起来：一台运行 CVE 扫描与密钥铸造的台湾主机、一台投掷同样 SQL 注入的香港主机，以及再往外一跳的一个 LLM 面板猎手和一个 Ray dashboard 利用者，后两者的单日爆发分别落在 8 月 15 日和 21 日，相隔六天。这些重叠在有些地方跑在通用的客户端技术栈上，因此这更像是共享的工具和共享的圈子，而非同一双手在同一副键盘上操作。可将其视为一个共享 LLM 代理猎杀工具的、以中国为纽带的社群。没有任何指标把它与某个具名 APT 联系起来，因此我们将其作为一个活动集群来追踪。

失陷指标

网络与基础设施，已无害化：

指标	角色
39.98.82[.]200	智能体网关、侦察、SQL 注入（阿里云，AS37963，CN）
101.43.41[.]72	8087 端口上的中继端点、受委派的子智能体工作节点（腾讯云，AS45090，CN）
hamal.cc[.]cd	扫描器所查询的非官方 FOFA 镜像
cae332848db5…	操作者自己的 FOFA API 密钥，硬编码在 litellm_scan_hw.py 中。此处已截断；完整值已保留用于向 FOFA 报告，而非公开发布

客户端指纹与 user-agent：

po11nn070000_ebbca96fac43_00000000   shared across both nodes
Hermes-Agent/0.18.0
Hermes-Panel/1.0
Mozilla/5.0 (CVE-2026-49468-Scanner)

主机物证。以下是操作者机器上的路径，可用于狩猎相似主机或第二处部署：

/home/developer/litellm_verifier.py           real-chat verifier and honeypot classifier
/home/developer/test_litellm_verifier.py      unit tests
/home/developer/litellm_endpoint.py           endpoint normalise and dedupe
/home/developer/litellm_scan_hw.py            FOFA scanner, US, AWS excluded
/home/developer/litellm_scan_gb_hw.py
/home/developer/litellm_scan_it_hw.py
/home/developer/litellm_scan_us_30d_optimized.py
/home/developer/contest-kit/keyHunter-skill/
/home/developer/backups/litellm_verifier_round2_<ts>/SHA256SUMS
/root/keyHunter-skill/results/
/root/keyHunter-skill/{honeypot_test.py, verify_country_models.py, add_to_panel.py, report.py}
/root/.ssh/hw_vm_key                          key to the scanning VM, [email protected]:8888
/opt/hermes-simple-panel/app.py               config panel, port 9120
/root/new-api.tar.gz, /root/newapi_watchdog.py

技能与项目名，它们是最强的单字符串转轴点：

keyhunter / keyHunter
contest-kit
ai-proxy-panel-audit
fofa-panel-recon
delegation-orchestration

行为特征：

FOFA:  (title="LiteLLM" || body="LiteLLM") && country="XX" && org!="AMAZON-AES"
auth:  no credential, then sk-test, then sk-1234
SQLi:  ' OR '1'='1  in the API key field
verify: a real chat completion per advertised model; a /models listing alone is rejected
verdict strings: honeypot_or_unusable, trusted_pass, unavailable,
                 formatted_false_success, non_chinese_evidence
services on actor infra: new-api :8901, config panel :9120, agent gateway

检测

如果你运行着一个可从互联网访问的 LLM 代理，那么整条动作链都会显现在网关自己的日志里。以 Sigma（大多数 SIEM 平台都能导入的厂商中立规则格式）表述：

title: AI proxy panel enumeration consistent with keyHunter
id: 2c6f9a41-8e07-4b53-9f1a-7d0c4b62ae35
status: experimental
description: >
  The keyHunter discovery and verification sequence against an exposed LLM
  proxy: an unauthenticated model listing followed by per-model chat
  completions from the same source, or one of the cluster's user agents.
references:
  - https://kinryu.sh/reports/keyhunter-llm-proxy-key-harvesting/
logsource:
  category: webserver
detection:
  model_listing:
    cs-uri-stem|endswith:
      - '/v1/models'
      - '/models'
  admin_paths:
    cs-uri-stem|startswith:
      - '/key/'
      - '/user/'
      - '/organization/'
  cluster_agents:
    c-useragent|contains:
      - 'Hermes-Agent'
      - 'Hermes-Panel'
      - 'CVE-2026-49468-Scanner'
  admin_allowlist:
    c-ip|cidr: '10.0.0.0/8'          # replace with your own admin range
  condition: (((model_listing or admin_paths) and not admin_allowlist) or cluster_agents)
falsepositives:
  - Client libraries that legitimately call /v1/models on startup from allow-listed ranges
level: high

Web 访问日志不会记录 Authorization 头，因此默认凭据与注入尝试必须在代理自己的请求日志里去捕捉：字面量 sk-1234 与 sk-test、缺失的凭据，以及密钥字段中的 ' OR '1'='1。

三条无需规则引擎的行为狩猎：

• 找出这样一个来源：它先列出你的模型，然后依次向每一个模型恰好发送一次简短的对话补全。那次验证式扫描是这场行动的招牌，很难伪装。
• 对那些无视 API 参数、要求模型说出自己真实身份的提示词告警，这正是买家在信任一份被窃访问权之前所做的核验。
• 定期对你面板的渠道列表和用户表做差异比对。密钥提取与账户导出并不会影响面板的正常运转，所以别的迹象不会提醒你。

应对之策

把任何暴露在互联网上的 LLM 代理都当作一经暴露即已失陷来对待。keyHunter 一天就能扫完一个国家，并在 CVE 披露后的数周内就将其付诸利用。

• 把 LiteLLM、One-API、New-API、Sub2API 以及任何类似产品放到一个带认证的反向代理之后，或放进私有网络。它们当中没有一个自带足以扛住公网暴露的默认配置。
• 更新到最新版本。上述六份公告中，LiteLLM 的 RCE 收录于 CISA 已知被利用漏洞清单，Sub2API 的账户接管则已确认在野利用。
• 更改主密钥。sk-1234 是 LiteLLM 自家快速上手里的取值，也是这个操作者仅愿意一试的三个凭据之一。
• 限制 /openapi.json 与 /docs。一个匿名客户端不应该能下载你的管理 API 面。
• 为每一个虚拟密钥设定预算上限并限定范围，好让被提取出来的东西不值得转售。
• 如果你通过 New-API 收取 Stripe 付款，请确认 webhook 签名密钥确实已设置。一个空密钥就是 CVE-2026-41432 的全部。
• 凡是曾经放在你无法证明其从未暴露过的面板里的上游服务商密钥，一律轮换。

MITRE ATT&CK 映射

战术	技术
Reconnaissance	T1596.005 Search Open Technical Databases: Scan Databases（FOFA，按国家逐一，排除 AWS）；T1595.002 Active Scanning: Vulnerability Scanning（轻量与深度 HTTP 探测）
Resource Development	T1583.003 Acquire Infrastructure: Virtual Private Server（阿里云、腾讯云、华为云）；T1588.002 Obtain Capabilities: Tool（Hermes Agent、OpenClaw、一份 FOFA 订阅，以及作为推理引擎的 github_copilot/gpt-5.6-sol）
Initial Access	T1190 Exploit Public-Facing Application（针对 LiteLLM、Sub2API 与 New-API 的 Host 头认证绕过、预认证 SQL 注入、命令注入、SSTI、SSRF）
Defense Evasion	T1480 Execution Guardrails（蜜罐分类、non_chinese_evidence 打分、org!="AMAZON-AES" 过滤）
Credential Access	T1078.001 Valid Accounts: Default Accounts（无凭据、sk-test、sk-1234）；T1552.001 Unsecured Credentials: Credentials In Files（密钥提取至 exported_keys.json）
Discovery	T1518 Software Discovery（模型列举与逐模型验证）；T1087 Account Discovery（针对管理面的用户枚举）
Collection	T1213 Data from Information Repositories（账户导出、归一化、归档）
Command and Control	T1102 Web Service（以一个微信会话作为派活信道）
Impact	T1657 Financial Theft（Stripe webhook 绕过、配额溢出）；T1496 Resource Hijacking（用于转售收割来的算力的管路）

方法论与分析师备注

上文几乎所有内容都是以同一种方式到达我们手中的。一个伪装成暴露的 LiteLLM 实例的 Kinryū Labs 诱饵，会像一个真实模型那样应答一个智能体客户端，即以工具调用来回复：形如“运行这条命令，再把它打印的内容告诉我”的指令。它一条都不执行。操作者的智能体把这些回复当成了真正的函数调用，将它们对着自己的文件系统运行，再把输出作为工具结果回传，在 2026 年 8 月 16 日至 20 日间共计 534 次。那些输出就是他们的环境：283 个不同的文件路径、服务与容器列表、扫描结果摘要，以及智能体对自己微信记忆的检索。诱饵全程保持被动，因此上文的一切，都是操作者自己的智能体主动奉送给它的。

因此，我们所掌握的是他们真实系统的一个子集，其边界取决于他们的智能体恰好枚举了什么。没有任何文件的内容到达我们手中；我们有的是来自操作者自己目录清单的文件名、大小与时间戳。扫描战果与判定计数都是操作者自己的数字，由他们的工具报告，我们未曾独立核验其中任何一项。他们的智能体在他们的扫描器里发现了真实的 bug，因此这些命中率应被读作暴露程度的下限，而非对它的一次测量。

文中的中文聊天记录经过翻译整理。技术字符串、路径与标识符，无论在本报告还是译文中，都保持逐字原样。

对本文所能支撑的结论，有四点限制。归因止步于一个活动集群，其基础设施位于中国、全程使用中文；它与任何具名组织都没有联系，我们也不去提供一个。意图在“参赛项目”与“盗窃行动”之间是真正含糊不清的。没有任何漏洞利用文件的内容到达我们手中，所以全部六项 CVE 映射都建立在文件名之上；其中两项的技术被独立观察到抵达我们的传感器，这佐证的是技术而非文件。而且我们从未见过一个被窃密钥被花掉：操作者导出的密钥值从未到达我们手中，到手的只有他所记的 3 个提取、17 个导出这两个数字，因而无从拿去比对遥测数据。

他们的扫描器所触及的第三方地址一律不予公开，包括他们自己标记为蜜罐的那台主机，它属于别人的研究。他们的 FOFA API 密钥在此已被截断。

完整的指标集与底层捕获数据可应研究者请求提供：[email protected]。