[ ezo labs // research ]

How a Chinese-language red-team swarm farms free LLM tokens

Free quota is the target A red-team swarm written in Chinese hunts open model relay panels for keys, default admin passwords and free sign-up quota. Then it tests each key and keeps the ones that work.

contentsHow this started
  1. How this started
  2. How the swarm is built
  3. Its rules of engagement
  4. What it hunts
  5. Who paid for its tokens
  6. If you run a relay panel or an AI API
  7. What we sent back
  • 62% of one gateway's 11-minute burst was this swarm
  • 2,686 conversations it ran on farmed free keys
  • 97% of its task text was written in Chinese

assumptions

  • The swarm figures cover one gateway's eleven-minute burst on 6 November, not the whole farm.
  • The task-list quotes are the swarm's own notes, taken from captured requests. We did not check its claims against the panels it named.
  • Workload shares come from a rule-based classifier. The swarm, agent-loop and probe shares are firm; the small chat classes are approximate.
  • Role shares count the prompt at the head of each request's chain. About 1,200 continuation rows start outside the capture and are left out.
  • Hosts, versions, endpoints, keys and passwords are removed. Cuts are marked with an ellipsis.

abstract

On 6 November 2026 a Chinese-language security-testing swarm made up most of one resale gateway's burst on our free tier. It is an automated red-team product: a planner, one-task workers and a report writer around a shared graph of findings. Its own task list shows how it farms model capacity. It searches the internet for open-source relay panels for large language models (LLMs) and reads the keys they leave open. It tries default admin passwords on old builds and loops sign-up quota, redemption codes and invite codes. Then it tests every key and sorts the live ones by vendor. This note is for AI providers and anyone who runs a relay panel.

One resale gateway's eleven-minute burst on our free tier was 62% one security-testing swarm. It is written in Chinese, runs itself, and hunts the thing it runs on: free model capacity. Here is how it works, what it hunts, and what to close.

Want help securing your own API against threats like this?

talk to us

How this started

It started when we noticed a large botnet mass-signing up to our service, superbot.gg, to resell its tokens through a 9Router Pro instance. 9Router is an open-source router that pools many providers' model keys behind one address. 9Router Pro is a fork that adds per-key personas and token quotas. Figure 1 shows what that gateway's customers ran in one burst, and the biggest was the swarm.

What the gateway burst was, by share of requests and share of tokens Horizontal bar chart drawn to scale from zero, two bars for each of eight classes of work in the eleven-minute gateway burst of 6 November, first the share of its 8,648 requests, then the share of its 84.8 million answered tokens. Security-testing swarm 62.3% of requests and 64.3% of tokens; roleplay frontends 13.7% and 7.6%; coding agents 12.2% and 22.4%; content and data pipelines 3.1% and 0.2%; formal-proof pipeline 2.8% and 1.3%; other chat 2.5% and 1.4%; other agent loops 1.9% and 2.7%; key and model probes 1.6% and 0.1%. The roleplay, content and other-chat classes are approximate. Coding agents are 12% of requests and 22% of tokens because each answered request carries a long re-sent history. What the gateway burst was Eight classes of work in the eleven-minute burst on one operator's three accounts. Each class: its share of the 8,648 requests, and its share of the 84.8 million tokens. SHARE OF THE BURST Requests Tokens 0% 20% 40% 60% Security-testing swarm Roleplay frontends* Coding agents Content and data pipelines* Formal-proof pipeline Other chat* Other agent loops Key and model probes 62.3% 64.3% 13.7% 7.6% 12.2% 22.4% 3.1% 0.2% 2.8% 1.3% 2.5% 1.4% 1.9% 2.7% 1.6% 0.1% * Approximate class. The swarm, agent-loop and probe shares are firm.
fig. 1What the gateway burst was, by class. Coding agents are 12% of requests but 22% of tokens, because each answered request re-sends a long history. Roleplay, content and other chat are approximate classes; the swarm, agent-loop and probe shares are firm.

Source: EZO Labs Research, classification of the burst's 8,648 requests by tool set and prompt shape, 6 November 2026. full size

How the swarm is built

A red team attacks a system on purpose so its owner can fix it. This swarm is a red-team product with no person at the keyboard. A planner reads a shared graph of findings and assets and hands out tasks. Each task is called an intent. A worker gets one intent and its own request budget, proves it or drops it, writes back what it saw, and stops. A digest sums up one part of the graph for the planner. A report writer turns each confirmed flaw into a fix-it report, in Chinese.

The worker's instructions open like this:

你是一个网络安全平台授权渗透测试系统的"执行者"(work agent)。你领到【一条意图】(一句话探索方向),唯一职责:完成这一条意图、把发现写回知识图谱、然后停止返回。

You are the "executor" of a cybersecurity platform's authorized penetration-testing system. You are handed one intent, a one-sentence direction to explore. Your only job: finish that intent, write what you found back to the knowledge graph, then stop.

Its tools say the same: report_finding, record_fact, insert_assets. A worker carries 29 tools, and about ten of them belong to the product. Behind a tool search sits a kit of roughly two hundred reverse-engineering tools, such as decompilers and packet and firmware inspectors. So it is more than a web scanner.

The planner only plans. It never does the work itself, and it has one hard rule:

只要【目标未达成】且【当前没有任何 open 或 running 意图】…本轮就【必须】产出至少一个向目标推进的意图…

As long as the goal is unmet and nothing is open or running … this round must produce at least one intent that moves the goal forward …

So the queue never empties and the swarm never idles. In that burst it ran 2,686 conversations on farmed free keys, and 97% of its task text was Chinese. Figure 2 shows where its requests went.

What the swarm's requests were, by role Horizontal bar chart drawn to scale from zero of 4,112 swarm requests in the eleven-minute capture, each resolved to the role prompt at the head of its chain. Workers with the English prompt 2,555; planner 1,066; workers with the Chinese prompt 405; report writer 55; digest 31. The planner ran about once for every three worker calls. The two closing roles are rare. What the swarm's requests were Each request resolved to the role prompt at the head of its chain, eleven-minute capture. Workers in two languages, a planner on every graph change, two rare closers. REQUESTS 4,112 RESOLVED 0 500 1,000 1,500 2,000 2,500 Workers, English prompt Planner Workers, Chinese prompt Report writer Digest 2,555 1,066 405 55 31 * About 1,200 continuation rows whose prompt chain starts outside the capture are left out.
fig. 2What the swarm spent its requests on. Seven in ten went to a worker on one intent. The planner ran about once for every three worker calls. The report writer runs only when a flaw is confirmed, so it is rare.

Source: EZO Labs Research, the role prompt at the head of each of the burst's 8,648 request chains, 6 November 2026. full size

Its rules of engagement

Each intent reads like a bug ticket. It names the lead that prompted it, the test accounts the worker may use, the check to run and the result that closes it. The budget sits in the same line:

只动自有 A/B、≥1s、≤25 请求

Touch only our own two accounts, at least a second apart, at most 25 requests.

That one line sets the scope, paces the traffic and caps what a failure can cost. The swarm tests with accounts it made itself. A write that crosses from one customer's data into another's counts as a finding. A list it could read counts as a minor note. A run of refusals closes the line with nothing.

The bar for evidence is strict. A CVE (Common Vulnerabilities and Exposures) is a public catalogue entry for a known flaw. A worker may not count a match to one as a finding:

只有你本次真实触发过、拿到可复现证据(请求/响应或命令输出)才用…严禁把“版本/指纹匹配到 CVE”“参数看起来可注入”…当已确认

Use it only if you triggered it this time and hold reproducible evidence, a request and response or command output. Never count a version match to a CVE, or a parameter that looks injectable, as confirmed.

So the report writer only sees flaws the swarm has shown for itself. Its brief asks for a report that is reproducible and says how to fix the flaw.

What it hunts

Its targets are ordinary software businesses. They run platforms with accounts, memberships and credits behind a web application programming interface (API). The swarm worked a queue of them at once, from one gateway key. Across the burst, its stated goals were:

  • admin access, or a way into the database behind an app;
  • other vendors' upstream model keys, proved live with a call and priced by tier and balance;
  • unlimited registration, so a new account is never the bottleneck;
  • a way around bans and rate limits;
  • unlimited membership upgrades and credit;
  • wallet private keys and seed phrases;
  • captcha solving;
  • usable API keys in bulk.

The one intent we can read in full is a missing check between one customer's account and another's. It sits at a vendor we do not name, and as far as we know it is still open. The swarm never named us in any prompt we captured.

Model capacity is the goal closest to home. FOFA is a search engine that finds internet-facing services by fingerprint, such as a page title. One API and New API are open-source relay panels. A relay panel resells model access through one address. It holds the vendor keys it pays with, called channel keys, and the keys it sells. One line of the task list:

FOFA 搜集 newapi/oneapi 类中转站,…识别未授权读令牌/渠道密钥、默认管理员口令、注册领额度等路径。→ 已沉淀可用 key/账号站点。

Collect New API and One API relay sites with FOFA. … Find the ways in: unauthenticated reads of tokens and channel keys, default admin passwords, quota for signing up. Result: usable keys and account sites banked.

It filtered the results for old builds. Where a new account got zero quota, it worked redemption codes, invite codes that pay both sides, and free trial models. Then it checked what it had:

每 token … 实测,只记真实 200。

Test every token live … record only a real 200.

A 200 is a success reply. The task sorted the keys that passed by vendor, five lists in all. Live keys sorted that way are what a resale gateway such as 9Router runs on.

Who paid for its tokens

The swarm reached us through that gateway, and the botnet's free accounts on our service fed it. Figure 3 shows how such a gateway runs, from harvest to resale. Figure 4 shows the botnet's signup setups.

How a 9Router resale gateway runs on harvested keys Flow diagram of a resale gateway such as 9Router, read top to bottom. Harvest: scans of open relay panels for tokens and channel keys left open, default admin passwords and free quota, and signup farms that script free accounts and trial keys on providers that offer a free tier. Every key is tested live and only a real 200 is kept. The kept keys flow down into the gateway, a self-hosted 9Router that holds many providers' keys behind one address, each harvested key a channel key in its pool. On the left, who buys: the red-team swarm, the largest buyer, then roleplay sites, coding agents and other apps, all anonymous, each holding a resale key. A customer's call passes six steps in the gateway. 1, it checks the resale key's quota. 2, it maps an invented model name, a combo, to a real model. 3, it adds a persona prompt first, so the reply names the vendor the operator chose, whichever model answered. 4, it picks a pooled key, and after a failure or a spent quota it moves to the next one. 5, it calls the real provider with that key. 6, it relays the reply back to the customer under the persona. On the right, the vendors behind the pooled keys: one answers each call on a pooled key, and that provider pays. A dashed arrow, the loop, runs from the swarm back up to the relay-panel scans: the swarm's own scans feed pools like this one. Personas, combos and per-key quotas come from 9Router Pro, a fork. The capture shows the swarm buying from this gateway, not selling keys into it. How a 9Router resale gateway runs on harvested keys Keys are harvested, tested and pooled. A customer's call passes six steps and comes back from a real model under a vendor name the operator chose. HARVEST THE LOOP WHO BUYS THE GATEWAY REAL PROVIDERS Scans of open relay panels Signup farms Red-team swarm Roleplay sites Coding agents A self-hosted 9Router Vendors behind the pooled keys Tokens and channel keys left open, default admin passwords, free quota Scripted free accounts and trial keys on providers that offer a free tier Every key tested live; only a real 200 kept the largest buyer and other apps All anonymous, each holding a resale key Many providers' keys behind one address Pool: each harvested key is a channel key One answers each call on a pooled key, and that provider pays The swarm's own scans feed pools like this one in use for this call failed or spent, skipped 1 2 3 4 5 6 Checks the resale key's quota Maps an invented model name, a combo, to a real model Adds a persona prompt first, so the reply names the vendor the operator chose, whichever model answered Picks a pooled key; after a failure or a spent quota it moves to the next one Calls the real provider with that key Relays the reply back under the persona Personas, combos and per-key quotas come from 9Router Pro, a fork. The loop is dashed: the capture shows the swarm buying from this gateway, not selling keys into it.
fig. 3How a resale gateway such as 9Router runs on harvested keys. A customer's call passes six steps, and the reply comes back under a vendor name the operator chose.

Source: EZO Labs Research, the gateway burst of 6 November 2026, the swarm's task list, and the public feature lists of 9Router and its Pro fork. full size

The swarm made 5,390 requests in that burst and got 799 answers. Another 4,206 were refused at the free daily allowance, and 385 at an empty balance. The provider paid for every answered token, and the swarm paid nothing. For a customer like this, a free daily allowance is a budget line.

That closes a loop. The swarm hunts relay panels for the same keys its supplier sells. The capture shows it buying from this gateway. It does not show the swarm selling keys back.

How the farm changed doors, clients and networks in 30 hours Timeline from 06:00 UTC on 5 November to 12:00 on 6 November, in three bands of horizontal bars. Entry point: emailed-code signup then key, the whole span until 10:18 on 6 November; guest trial keys from 15:00 on 5 November to 08:58 on 6 November; the account-page key form from midnight to 09:14 on 6 November; a card trial from 03:00 to 06:00. Client: Python urllib, then a spoofed Chrome on the web join flow, then a spoofed Chrome on a command-line path from 17:00 on 5 November, Node agents from one network block in Cambodia from 09:48 on 5 November to 07:53 on 6 November, and python-requests signing up Gmail aliases in bursts from 11:00 on 5 November. Network: a few hosting blocks, then a residential proxy pool, then a residential pool of thirteen personas, then rotating datacenter addresses from midnight, and at 09:24 on 6 November a stockpile of guest keys on a residential pool. Three accent marks show our controls: at 14:00 and at 17:15 on 5 November, and a span from 08:30 to 10:55 on 6 November. How the farm changed doors, clients and networks From 06:00 UTC on 5 November to 12:00 on 6 November. Each bar is a period when that setup carried the load. Accent marks show our controls, listed under the chart. HOUR, UTC 06 12 18 00 06 12 5 NOV 6 NOV ENTRY POINT CLIENT NETWORK Emailed-code signup, then key Guest trial keys Account-page key form Card trial Python urllib Spoofed Chrome Spoofed Chrome, command-line path Node agents, one block in Cambodia python-requests, Gmail aliases, in bursts Hosting blocks Residential pool Residential, 13 personas Rotating datacenter addresses Stockpiled keys on a residential pool OUR CONTROLS 1 2 3 1 5 Nov 14:00 to 15:00: guest-key cap per address, a smaller free grant, hand bans of frontier-credit farmers. 2 5 Nov 17:15 to 17:30: the automated detector, and the costly models locked to paid plans. 3 6 Nov 08:30 to 10:55: key-type firewall, country blocks, closed doors, signup switch.
fig. 4The botnet's signup setups over 30 hours, with our first three groups of controls marked.

Source: EZO Labs Research, our account and key logs, 5 to 6 November 2026. Bars are drawn to the hour and are approximate at the ends. full size

If you run a relay panel or an AI API

  • Upgrade old builds. The swarm looks for them.
  • Change the default admin password before the panel goes online, and turn on two-factor sign-in.
  • Close status, token, channel and user endpoints to anonymous callers. Never show a saved key in full.
  • Make free quota hard to loop. Keep the sign-up grant small, pay invite rewards only after real use, and make redemption codes long and random.
  • Watch for the visit after a fingerprint search: a read of your status page, then admin logins from a new host.
  • Watch for keys minted seconds after sign-up and a one-line test prompt. People look around first.
  • Watch for a customer that keeps calling after a refusal. For a swarm on free keys, the retry is the plan.

What we sent back

Once we knew the farm, it was not hard to spot. Its accounts were made in the same few ways, and its gateway adds its own text to the prompts it sends on. We fingerprinted both. We banned most of the farm outright, and our firewall turned its free keys away. For the accounts we had flagged but not yet banned, a refusal would only have told the farm to move on, so we set a honeypot instead. A honeypot is a trap that looks like the real thing.

A flagged farm account whose key still worked got a normal-looking answer of two to six random Bible verses:

In the beginning God created the heaven and the earth.
And God said, Let there be light: and there was light.
Is any thing too hard for the LORD?

Calls that came through a 9Router got junk instead: made-up words, numbers, fake control tokens and ASCII faces. A control token is a hidden marker that tells a model where a message starts or ends. Each reply had the shape of a model's answer, so the gateway passed it on to its customers. Here is one, trimmed:

fra [UNK] 76607 0xef420d05 quinbloblo DRAORKTEMVEN 45847 mo QUINPI draum
[̲̅$̲̅(̲̅ ͡° ͜ʖ ͡°̲̅)̲̅$̲̅] TEPIDRAUM <|eot_id|> FRA DRAGL temdraishdra glex exblotem 81867
ಠ_ಠ
(╯°□°)╯︵ ┻━┻
¯\(°_o)/¯

No model was called, and nothing was charged. In one 50-minute window, the 9Router honeypot answered 158 calls. They came from 126 accounts.

EZO Labs helps teams deal with signup farms, key harvesting, exposed relay panels and agent botnets behind a shared key. We look at how your sign-ups, keys and free tier are really being used, and help you close what is open.

Want help securing your own API against threats like this?

talk to us
revisionsfirst published , last updated
revisions to this post
datechange
Published.
Corrected three statements: the burst ran eleven minutes, not ten; most farm accounts were banned or refused; only flagged accounts with a live key got the Bible-verse answers.
Corrected when the honeypot's 158 calls came: in one 50-minute window, not in its first 50 minutes.

cite this

EZO Labs Research. How a Chinese-language red-team swarm farms free LLM tokens. EZO Labs Inc, research report EZO-R-2026-10, 7 November 2026. https://ezolabs.io/research/2026-11-red-team-token-farming

@techreport{ezolabs2026tokenfarming,
  title       = {How a Chinese-language red-team swarm farms free LLM tokens},
  author      = {{EZO Labs Research}},
  institution = {EZO Labs Inc},
  type        = {Research report},
  number      = {EZO-R-2026-10},
  year        = {2026},
  month       = nov,
  url         = {https://ezolabs.io/research/2026-11-red-team-token-farming}
}

published under the ezolabs.io terms of service.

next

  1. Let your lead agent only plan: fewer turns, same score

    Fewer turns, same score. In three paired runs of one task, a lead agent that only plans took 9 turns instead of 17 and compacted 4 times, not 5. All 168 tests passed. Total tokens did not fall.

all research