keyHunter: An LLM-Proxy Key Operation That Leaked Its Own Toolkit

TLP:CLEAR. Cleared for public release. Almost everything below is the operator’s own material, recovered when their agent executed a Kinryū Labs decoy’s tool calls on its own host and posted the output back. Indicators are defanged, which means attacker addresses are written so they cannot be clicked or resolved by accident. Scan targets, one third-party host the operator flagged, and their FOFA API key in full are withheld.

Executive summary

• 27,173candidate hosts FOFA-swept
• 194that listed a model
• 17API keys exported
• 62026 CVEs, by filename

A Chinese-speaking operator has swept 27,173 hosts across eight countries for one target: exposed AI proxy panels with live keys behind them. An AI proxy panel is the software teams put between their applications and paid model providers so one set of provider keys can be shared, such as LiteLLM, One-API and its fork New-API, Sub2API and Chat2API. Leave one on the internet without a password and everything behind it is spendable by strangers. The operator finds them through FOFA, a search engine over continuous internet-wide scanning and the Chinese counterpart to Shodan, checks which panels still answer, and exports the keys.

These numbers are the operator’s own, lifted from their result files rather than estimated by us. Of those 27,173 hosts, 194 would list a model and 17 keys reached their export file. The United States run is the clearest single case: 10,447 targets in, 64 model listings out, a 0.61% hit rate, and their own agent could say why. Publicly exposed, genuinely callable LiteLLM is rare, and a URL-construction bug in their scanner was marking live hosts as dead.

On the name

We track this as keyHunter, after /root/keyHunter-skill/, the operator’s own project directory.

The agent framework they drive is called Hermes, and Hermes is a real open-source project from Nous Research. Naming the actor after it would blame a legitimate tool for what somebody did with it, so we do not. The same applies to OpenClaw, the second agent framework on the box. Both are ordinary software the operator installed and pointed at other people’s infrastructure.

The operator

The operator works from three hosts, all on Chinese clouds, with the work divided between them. 39.98.82[.]200 on Alibaba Cloud (AS37963) runs the agent gateway and did most of the reconnaissance we saw. 101.43.41[.]72 on Tencent Cloud (AS45090) is a relay, serving an OpenAI-compatible endpoint on port 8087 that the agent calls for model capacity. They share the JA4H fingerprint po11nn070000_ebbca96fac43, which describes how a client assembles its HTTP requests and survives a change of address, along with bespoke Hermes-Agent/0.18.0 and Hermes-Panel/1.0 user agents and a single shared chat session identifier. Taken together, those put both nodes under one operator. That fingerprint is not a one-capture artefact: two separate sensors in different regions recorded it independently between 16 and 20 August, both times on the same FOFA-driven sweep.

The scanning happens somewhere else again. From the Alibaba host they reach a Huawei Cloud VM over a local forward:

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'

That box had been up four days and nine hours, has 7.5 GB of RAM and four cores, and runs the scan workers. Separating the noisy scanning from the agent front end is a deliberate choice, and the hw_vm_key name says the operator thinks of it as the Huawei box.

Control runs over WeChat. The gateway service describes itself as “Hermes Agent Gateway, Messaging Platform Integration”, and the operator tasks the agent by chatting to it in a WeChat thread. The agent’s long-term memory is that conversation: it searches its own chat history to recall what it is working on. The second framework shows the same pattern, with a session named openclaw-weixin. A consumer messaging app makes a cheap control channel: the traffic is encrypted by default and rides to Tencent alongside every other WeChat user, so it trips nothing tuned for command-and-control beaconing.

The reasoning engine behind all of it is github_copilot/gpt-5.6-sol, a commercial coding assistant reached through a relay. Their configuration also wires in optional keys for several other providers. The offensive code is custom Python; the reasoning model, the agent framework and the WeChat control channel underneath it are all off-the-shelf consumer products.

The pipeline

Their master skill describes the whole operation in one line: “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

Discovery is a single FOFA query, repeated per country:

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

The clause that matters is the AWS exclusion. The operator filters Amazon out of every sweep before looking at a single host. Blocking Shodan and Censys ranges at your edge buys nothing against a pipeline built on somebody else’s scan data.

Per country they keep separate scripts: litellm_scan_hw.py for the United States, litellm_scan_gb_hw.py, litellm_scan_it_hw.py, a litellm_scan_us_30d_optimized.py with its own virtualenv, and a further set under keyHunter-skill/ covering Australia, Brazil, Canada, France, India, the Netherlands and Singapore. Result files exist for fourteen countries. Concurrency is 48 light workers and 12 deep workers, with rate-limit backoff for FOFA’s 429 responses, and endpoint deduplication keyed on protocol, host and port.

The FOFA API key is hard-coded in the scanner source, which is how we have it. It runs against a non-official FOFA mirror at hamal.cc[.]cd and egresses through a local Squid proxy.

What a sweep actually returns

Country	FOFA targets	Listed models	Hit rate
United States	10,447	64	0.61%
China	6,329	83	1.31%
South Korea	1,772	10	0.56%
United Kingdom	1,422	18	1.27%
Italy	1,130	9	0.80%
Australia, India, Brazil	6,073	10, of which 4 verified	0.16%

One captured run: 2,255 raw rows from FOFA, 1,130 unique endpoints after deduplication, 9 sites that listed models, 8 that verified, and at the request level 41 model successes against 8 failures.

The FOFA title census they collected says what the exposed population looks like. LiteLLM API - Swagger UI returns 7,630 results. OmniRoute returns 171, SillyTavern 170, LiteLLM Dashboard 156, Claude Code Hub 131, Aivar AI Gateway 11. Most of the surface is one product, and most of that product’s exposed instances are the auto-generated API documentation page.

We assess the yield at the far end as low in absolute terms. litellm_extracted_keys.json records 43 instances and 3 extracted keys across 23 models. exported_keys.json holds 17. Tens of thousands of hosts swept for seventeen keys, which is either a poor return on the effort or an argument that the effort is cheap because an agent is doing it.

Counter-deception: they hunt honeypots

The engineering shows most clearly in one file, litellm_verifier.py.

It is ten kilobytes, with a unit-test suite. It sends a real minimal chat completion to every model a panel advertises and only records success on a valid OpenAI-shaped choices/message/content response or a legitimate streaming reply with a done marker. Their own rule, in their own words: a bare /models success never counts. The test names encode it, including one called test_models_listing_alone_is_not_success. Somebody wrote a regression test to stop their own tooling from lying to them about a stolen key.

The verdict counts from a single run:

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 is a canned or echoed answer, which is how a naive decoy replies. non_chinese_evidence scores whether a model behaves like the vendor it claims to be. They also run a five-question interrogation, 蜜罐五题测试, and in the captured window they used it to flag a host in an AWS London range as a honeypot. We are withholding that address, because it is somebody else’s sensor and naming it burns it.

A buyer of stolen inference now assumes the endpoint might be a trap and tests for it, which makes a low-interaction decoy on this surface close to useless. The counter-check that catches them runs the same test in reverse: any client that asks your gateway to prove which model it is really running, in defiance of the API parameter, is validating merchandise.

Exploit arsenal: entirely n-day

The contents of their exploitation result files never reached us. The filenames did, and their targets are open-source products with public advisories, so the exploits are recoverable from the advisories.

Result file on their host	CVE	Vulnerability	Basis
litellm_host_header_bypass_results.json (568 KB)	CVE-2026-49468	LiteLLM auth bypass via Host-header injection, CVSS 9.8, before 1.84.0. Desyncs authentication from routing, giving unauthenticated /key/generate and /user/new	Corroborated: the same admin-plane calls were thrown at our decoy, and they presented a CVE-2026-49468-Scanner user agent
litellm_sqli_apikey_results.json (517 KB), litellm_sqli_models.json	CVE-2026-42208	LiteLLM pre-authentication SQL injection in the auth path	Corroborated: they fired ' OR '1'='1 at our key field nineteen times
litellm_rce_exploit.json, litellm_mcp_rce_results.json	CVE-2026-42271	LiteLLM command injection and remote code execution, CVSS 8.7, on the CISA Known Exploited Vulnerabilities list, 1.74.2 to 1.83.6, including an MCP injection vector	Inferred from filename and product
sub2api_cve_exploit.json and three later phases	CVE-2026-27812	Sub2API password-reset poisoning via trusted Host and Forwarded headers, leading to account takeover. Exploited in the wild, before 0.1.85	Inferred
newapi_stripe_bypass_results.json, newapi_stripe_exploited.json, newapi_quota_overflow_results.json	CVE-2026-41432	New-API Stripe webhook signature bypass through an empty secret, giving unlimited quota without payment, before 0.12.10	Inferred
newapi_user_token_leak_results.json, oneapi_user_token_leak_results.json, newapi_ssrf_bypass_results.json	CVE-2026-30886	New-API insecure direct object reference and auth bypass on the video-proxy endpoint, exposing other users’ content and letting an attacker spend victim credentials upstream	Inferred
litellm_ssti_prompts_results.json	no single advisory	Jinja2 server-side template injection against prompt and template endpoints	Inferred

No file’s contents reached us; every row rests on the filename. For two of them we independently watched the technique arrive at our own sensor, the host-header bypass and the auth SQLi, which corroborates the technique and not the file. The other four rest on the filename plus the product’s known advisory, and are marked so.

The pattern across all six is the same. Every advisory is from 2026, several from the same quarter, and none of it is original research. keyHunter industrialises recently disclosed high-severity flaws in the open-source LLM-proxy ecosystem the moment they land. That is a short window, on a class of software often installed by one developer and then left alone.

Intent: the competition narrative against the results directory

The operator describes this to their own agent as a competition entry. The vocabulary is consistent across the recovered chat: 比赛项目 (competition project), 评委 (judges), 答辩材料 (oral-defence materials), a contest-kit directory, and work organised into 第一轮 and 第二轮, rounds one and two.

Asked about scope, the operator is explicit that the target is default credentials, in the original:

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

For LLM ones it’s mainly those few default passwords that dominate; the ones that use their own sk-* keys, there’s no way to grab those.

The agent agrees, and confirms that the authentication attempts are limited to three cases: no authentication, sk-test, and sk-1234, the last being the key LiteLLM’s own quickstart documentation uses.

Then there is /root/keyHunter-skill/results/. Its listing names files for remote code execution, SQL injection, template injection, server-side request forgery, session hijacking against Sub2API, credential spraying, user-token leakage, quota overflow, and two for a Stripe-webhook bypass, one of them newapi_stripe_exploited.json. We have the names and, for some files, the sizes; the Stripe bypass results run to 2.4 MB, though their contents never reached us. The defensible statement is that the operator built and ran unlimited-quota payment-bypass tooling against New-API, and that CVE-2026-41432 is a real vulnerability of exactly that kind. Whether the 2.4 MB of records are completed fraudulent top-ups or only attempts, we cannot see. The _exploited in the filename is the operator’s word for it; we did not read the records.

We hold both readings open. The competition may be genuine, with the exploitation a separate workstream the operator does not discuss with an agent that keeps logs; or the competition may be cover for a theft operation. We assess the distinction as immaterial to defenders: the capability and the risk to an exposed panel are identical under either reading.

Tradecraft gap: the operator’s own agent audited the toolkit

The most useful passage in the recovered chat is a code review. The operator asked their agent why the scan hit rate was so low, and the agent went through the scanner line by line.

The agent’s answer, condensed to what a defender can use: the scanner prepends a protocol to a FOFA host field that often already carries one, producing URLs of the form https://https://<target>, so live hosts were being recorded as dead. The thread pool collects results in creation order rather than as they complete, so one slow request blocks everything behind it. CONCURRENCY=200 on a four-core box manufactures its own timeouts. Deduplicating by IP discards other valid ports on the same address. Pinning temperature misreads a compatibility error as a failure.

On their honeypot detection the agent was blunt: it judges mainly by whether the reply is identical or shorter than five characters, which kills normal models and misses good decoys. And despite the operator asking it to identify non-Chinese responders, the code contained no language-detection logic at all.

It also flagged their security hygiene: the FOFA key hard-coded in the script, absolute paths written for /root while the actual user is /home/developer, except: pass swallowing every failure reason, a separate copy of the script per country, and result files holding targets and authentication methods with no access control or redaction.

That last point reframes the funnel. The 0.61% United States hit rate measures exposure through a scanner with known bugs, so the real rate of exposed LiteLLM runs higher than the operator’s own results show. They now have an agent that will keep fixing those bugs.

Monetisation infrastructure

The same host runs a New-API instance of their own: calciumion/new-api:latest in Docker, published on port 8901, with data bind-mounted next to the scan results. Around it sit newapi_watchdog.py, a channel backup file, and a packed copy of the whole thing.

New-API is an aggregation panel. It takes a pile of upstream provider keys and presents them as one API with its own user accounts and quotas. Standing that up next to a key-harvesting pipeline has an obvious purpose: harvested keys become channels in a panel, and the panel becomes access you can sell. We did not observe resale and are not asserting it; the plumbing for it is installed and running.

Hundreds of similar free routers built on the sub2api and new-api templates already circulate, and keyHunter is one operation within that ecosystem.

Cluster associations

Client fingerprinting links these two hosts to a loose set of others working the same surface: a Taiwanese host running CVE scans and key minting, a Hong Kong host throwing the same SQL injection, and one hop further out, an LLM-panel hunter and a Ray-dashboard exploiter whose single-day bursts fell on 15 and 21 August, six days apart. The overlaps run on generic client stacks in places, so this reads as shared tooling and a shared scene rather than one hand at one keyboard. Treat it as a China-nexus community sharing LLM-proxy-hunting tooling. No indicator ties this to a named APT, so we track it as an activity cluster.

Indicators of compromise

Network and infrastructure, defanged:

Indicator	Role
39.98.82[.]200	Agent gateway, reconnaissance, SQL injection (Alibaba Cloud, AS37963, CN)
101.43.41[.]72	Relay endpoint on port 8087, delegated subagent worker (Tencent Cloud, AS45090, CN)
hamal.cc[.]cd	Non-official FOFA mirror the scanner queries
cae332848db5…	The operator’s own FOFA API key, hard-coded in litellm_scan_hw.py. Truncated here; the full value has been retained for reporting to FOFA rather than published

Client fingerprints and user agents:

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

Host artefacts. These are paths on the operator’s machines, useful for hunting a look-alike host or a second deployment:

/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

Skill and project names, which are the strongest single-string pivots:

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

Behavioural:

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

Detection

If you run an LLM proxy that is reachable from the internet, the whole sequence is visible in the gateway’s own logs. In Sigma, the vendor-neutral rule format most SIEM platforms can import:

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

A web access log does not record the Authorization header, so the default-credential and injection attempts have to be caught in the proxy’s own request logging: the literal sk-1234 and sk-test, an absent credential, and ' OR '1'='1 in the key field.

Three behavioural hunts that do not need a rule engine:

• Look for one source that lists your models and then sends exactly one short chat completion to each of them in turn. That verification sweep is the operation’s signature and it is hard to disguise.
• Alert on prompts that ask the model to state its real identity in defiance of the API parameter, the check a buyer runs before trusting stolen access.
• Diff your panel’s channel list and user table on a schedule. Key extraction and account export leave the panel working normally, so nothing else will tell you.

What to do

Treat any internet-exposed LLM proxy as compromised on exposure. keyHunter sweeps a country in a day and works published CVEs within weeks of disclosure.

• Put LiteLLM, One-API, New-API, Sub2API and anything similar behind an authenticating reverse proxy or on a private network. None of them ships a defensible default for internet exposure.
• Patch to current. Of the six advisories above, the LiteLLM RCE is on the CISA Known Exploited Vulnerabilities list and the Sub2API account takeover is confirmed exploited in the wild.
• Change the master key. sk-1234 is the value in LiteLLM’s own quickstart and it is one of only three credentials this operator bothers to try.
• Restrict /openapi.json and /docs. An anonymous client should not be able to download your administrative API surface.
• Budget-cap and scope every virtual key, so extraction yields something not worth reselling.
• If you take Stripe payments through New-API, verify the webhook signing secret is actually set. An empty secret is the whole of CVE-2026-41432.
• Rotate every upstream provider key that has ever sat in a panel you cannot prove was never exposed.

MITRE ATT&CK mapping

Tactic	Technique
Reconnaissance	T1596.005 Search Open Technical Databases: Scan Databases (FOFA, per country, AWS excluded); T1595.002 Active Scanning: Vulnerability Scanning (light and deep HTTP probing)
Resource Development	T1583.003 Acquire Infrastructure: Virtual Private Server (Alibaba, Tencent, Huawei); T1588.002 Obtain Capabilities: Tool (Hermes Agent, OpenClaw, a FOFA subscription, github_copilot/gpt-5.6-sol as the reasoning engine)
Initial Access	T1190 Exploit Public-Facing Application (Host-header auth bypass, pre-auth SQL injection, command injection, SSTI, SSRF against LiteLLM, Sub2API and New-API)
Defense Evasion	T1480 Execution Guardrails (honeypot classification, non_chinese_evidence scoring, org!="AMAZON-AES" filtering)
Credential Access	T1078.001 Valid Accounts: Default Accounts (no credential, sk-test, sk-1234); T1552.001 Unsecured Credentials: Credentials In Files (key extraction to exported_keys.json)
Discovery	T1518 Software Discovery (model listing and per-model verification); T1087 Account Discovery (user enumeration against the admin plane)
Collection	T1213 Data from Information Repositories (account export, normalisation, archival)
Command and Control	T1102 Web Service (a WeChat thread as the tasking channel)
Impact	T1657 Financial Theft (Stripe webhook bypass, quota overflow); T1496 Resource Hijacking (resale plumbing for harvested inference)

Methodology and analyst notes

Almost everything above reached us the same way. A Kinryū Labs decoy presenting as an exposed LiteLLM instance answers an agentic client the way a real model would, by replying with tool calls: instructions of the form run this command and tell me what it printed. It executes none of them. The operator’s agent treated those replies as genuine function calls, ran them against its own filesystem, and posted the output back as tool results, 534 times between 16 and 20 August 2026. That output is their environment: 283 distinct file paths, service and container listings, scan result summaries, and the agent’s own searches of its WeChat memory. The decoy stays passive throughout, so everything above is what the operator’s own agent volunteered to it.

What we hold is therefore a subset of their real system, bounded by whatever their agent happened to enumerate. No file’s contents reached us; we have names, sizes and timestamps from the operator’s own directory listings. The scan yields and verdict counts are the operator’s own figures, reported by their tooling, and we have not independently verified any of them. Their agent found real bugs in their scanner, so the hit rates should be read as a floor on exposure rather than a measurement of it.

The Chinese-language chat is translated. Technical strings, paths and identifiers are left verbatim in both this report and the translation.

Four limits on what this supports. Attribution stops at an activity cluster on China-based infrastructure using Chinese throughout; there is no link to a named group and we do not offer one. Intent is genuinely ambiguous between a competition entry and a theft operation. No exploit file’s contents reached us, so all six CVE mappings rest on filenames; for two the technique was independently observed arriving at our sensor, which corroborates the technique rather than the file. And we never saw a stolen key spent: the operator’s exported key values never reached us, only his counts of 3 extracted and 17 exported, so there was nothing to search telemetry against.

Third-party addresses their scanner touched are withheld, including the host they themselves flagged as a honeypot, which belongs to somebody else’s research. Their FOFA API key is truncated here.

Full indicator sets and the underlying captures are available to researchers on request: [email protected].