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

TLP:CLEAR。已批准公开发布。下文几乎所有内容都来自操作者自己的材料，取自其智能体投送到我们某个蜜罐的输出。指标已做 defang 处理，即攻击者地址被改写成无法误点击、也无法被意外解析的形式。扫描目标、操作者标记出的一台第三方主机，以及其 FOFA API 密钥的完整值，均不予披露。

执行摘要

• 27,173经 FOFA 扫描的候选主机
• 194列出了模型的主机
• 17导出的 API 密钥
• 6依文件名判定的 2026 年 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 developer@127.0.0.1 \
    '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。消费级即时通讯应用是廉价的控制通道：流量默认加密，并与其他所有微信用户一同流向腾讯，因此不会触发任何针对 C2 心跳调校的检测。

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

处理流水线

他们的主技能文档用一句话概括了整套行动：“使用 FOFA + keyHunter + 自定义验证脚本，发现、扫描、验证并归档公网暴露的 AI API 代理面板（LiteLLM、Sub2API、New-API、One-API）。”

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 排除子句。操作者在看第一台主机之前，就把 Amazon 从每一轮扫描中过滤掉了。面对一条建立在别人扫描数据之上的流水线，在边界上封禁 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 密钥硬编码在扫描器源码里，我们也因此拿到了它。扫描器跑在一个非官方 FOFA 镜像 hamal.cc[.]cd 上，出口经由本地 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。

它约十千字节，配有一套单元测试。它会向面板公布的每个模型发送一次真实的最小 chat completion，只有在收到符合 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 与模板端点的 Jinja2 服务端模板注入	推断

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

六者的共同模式是一样的。每一份公告都出自 2026 年，其中数份出自同一季度，没有一项属于原创研究。keyHunter 在开源 LLM 代理生态中新披露的高危缺陷落地的那一刻就把它们工业化。那是一个很短的窗口期，而这类软件往往由一名开发者装好之后就无人问津。

意图：比赛叙事与结果目录的矛盾

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

被问到范围时，操作者明确表示目标是默认口令，原文如下：

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

对 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% 的美国命中率衡量的是一个已知有缺陷的扫描器所看到的暴露情况，因此 LiteLLM 的真实暴露率高于操作者自己结果所显示的水平。而他们现在有了一个会不断修复这些缺陷的智能体。

变现基础设施

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

New-API 是聚合面板。它把一堆上游厂商密钥汇总起来，对外呈现为一个 API，并自带用户账号和额度体系。把它架在密钥收割流水线旁边，用意很明显：收割来的密钥变成面板里的渠道，而面板变成可以出售的访问权。我们没有观测到转售，也不主张存在转售；但相应的管线已经装好并在运行。

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

集群关联

客户端指纹把这两台主机与一批同样盯着这个攻击面的松散主机联系起来：一台运行 CVE 扫描与密钥签发的台湾主机，一台投放同样 SQL 注入的香港主机，再往外一跳，还有一个 LLM 面板猎手和一个 Ray 面板利用者，二者的单日爆发分别落在 8 月 15 日和 21 日，相隔六天。这些重叠在部分环节跑的是通用客户端栈，因此更像是共享工具与同一个圈子，而不是同一人在同一个键盘前操作。应将其视为一个共享 LLM 代理猎取工具的中国关联社群。没有任何指标把它与某个具名 APT 关联起来，因此我们把它当作一个活动集群来追踪。

失陷指标

网络与基础设施，已 defang：

指标	作用
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, developer@127.0.0.1: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。

三条不需要规则引擎的行为狩猎思路：

• 找出这样的来源：它先列出你的模型，然后依次向每个模型发送恰好一条简短的 chat completion。那次验证扫描是这场行动的特征，且很难伪装。
• 对要求模型违背 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 映射

战术	技术
侦察	T1596.005 搜索开放技术数据库：扫描数据库（FOFA，按国家，排除 AWS）；T1595.002 主动扫描：漏洞扫描（轻量与深度 HTTP 探测）
资源开发	T1583.003 获取基础设施：虚拟专用服务器（阿里云、腾讯云、华为云）；T1588.002 获取能力：工具（Hermes Agent、OpenClaw、一份 FOFA 订阅，以及作为推理引擎的 github_copilot/gpt-5.6-sol）
初始访问	T1190 利用面向公众的应用程序（针对 LiteLLM、Sub2API 和 New-API 的 Host 头认证绕过、前置认证 SQL 注入、命令注入、SSTI、SSRF）
防御规避	T1480 执行护栏（蜜罐分类、non_chinese_evidence 打分、org!="AMAZON-AES" 过滤）
凭据访问	T1078.001 有效账户：默认账户（无凭据、sk-test、sk-1234）；T1552.001 不安全凭据：文件中的凭据（密钥提取到 exported_keys.json）
发现	T1518 软件发现（模型列表与逐模型验证）；T1087 账户发现（针对管理面的用户枚举）
收集	T1213 来自信息仓库的数据（账号导出、归一化、归档）
命令与控制	T1102 Web 服务（以微信会话作为派活通道）
影响	T1657 金融窃取（Stripe webhook 绕过、额度溢出）；T1496 资源劫持（为收割来的算力搭建的转售管线）

方法论与分析师说明

上文几乎所有内容都来自 2026 年 8 月 16 日至 20 日期间操作者自己的智能体投送到我们某个蜜罐的输出：283 条不同的文件路径、服务与容器清单、扫描结果摘要，以及该智能体对自身微信记忆的检索。

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

中文聊天记录经过翻译。技术字符串、路径和标识符在本报告及其译文中均按原样保留。

本报告所能支撑的结论有四点限制。归因止步于一个使用中国境内基础设施、全程使用中文的活动集群；没有与任何具名组织的关联，我们也不提供这种关联。在参赛项目与窃取行动之间，意图确实存在歧义。没有任何利用文件的内容到达我们手里，因此全部六项 CVE 映射都建立在文件名之上；其中两项的技术手法我们独立观察到抵达了自己的传感器，这佐证的是技术手法而非文件。被盗密钥后来是否被使用不得而知：操作者的输出只给出计数，提取 3 个、导出 17 个，没有任何可供追踪的密钥值。

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

完整指标集与底层捕获数据可应研究人员要求提供：contact@kinryu.sh。