TKFleet · AndroidRPA v8.1-wake2: A Chinese-Language Bot Farm Control Panel Running on Alibaba Cloud US

PublishedApril 21, 2026

TKFleet · AndroidRPA v8.1-wake2: A Chinese-Language Bot Farm Control Panel Running on Alibaba Cloud US

With thanks to @justwanttoQ1 for the tip that pointed us at this host. This writeup would not exist without the pointer. Any mistakes below are ours, not the tipster's — please reach out if you spot any, or if you've published prior work we've missed.

TL;DR

A Chinese-language bot farm control panel is publicly reachable on the internet at hxxp://47.251.111[.]98:8080/. It identifies itself as "TKFleet 云控平台" ("TKFleet Cloud Control Platform") in the login screen, and the HTML <title> tag stamps it as AndroidRPA · 云控平台 · v8.1-wake2.

The panel is built to manage 5,000 real Android handsets (explicit string: "管理 5000 台真机"), drive fake engagement on Spotify, YouTube, TikTok, Instagram, Facebook, and X, and has a purpose-built "account farming pool" mode whose stated goal is "让账号'活着'不被风控" — "keep the accounts alive so they don't get risk-controlled." It uses Anthropic's Claude Haiku as its vision-navigation fallback ("Tier B 视觉导航 · Linux 代理 Claude Haiku").

The host is Alibaba Cloud LLC (US region). The web layer is a Python 3.12.3 SimpleHTTP dev server serving a 142 KB single-page app on port 8080. Prometheus metrics (/metrics) are world-readable and confirm the deployment is live and in active use: rpa_http_requests_total climbs on the order of tens of requests per minute while this report was being written.

The control panel exposes an authenticated REST API, but the entire feature catalog is legible from the static HTML and JavaScript that the server hands out unauthenticated — including endpoint names, anti-risk-control parameters, the fake "Tencent" package name of the device-side APK (com.yyds.auto / com.tencent.yyds.MainActivity), and a default campaign template placeholder whose example text is "Rick Astley 订阅 × 500".

What This Report Adds to the Public Record

This report is the result of walking through a live, publicly-reachable control panel and documenting what the HTML and JavaScript it hands out unauthenticated already says about the product.

A feature-level map of the TKFleet · AndroidRPA v8.1-wake2 panel at 47.251.111[.]98, including its navigation structure, its 5,000-device target capacity, and its own internal version tag.
The target platform list — Spotify, YouTube, TikTok, Instagram, Facebook, X — together with the per-platform action catalog the panel defaults to (browse_fyp / like_video / follow_user / comment for TikTok; browse_home / search_artist / play_playlist / like_song / follow_artist for Spotify; equivalents for the other four).
The four execution backends the panel exposes as a first-class per-device dropdown: HID hardware injection, Android Accessibility-service abuse, Shizuku privileged IPC, and "auto".
The Android device-side package — com.yyds.auto — with a MainActivity scoped under com.tencent.yyds, which masquerades as a Tencent-owned class. Worth noting both for detection engineering and for Tencent's awareness.
The "v8.1 audit" subsystem with its six-state device lifecycle (PROVISIONING, ONLINE, DEGRADED, OFFLINE, QUARANTINED, RETIRED) and transition-evidence logging.
The panel's integration of Anthropic's Claude Haiku as the fallback visual-navigation agent, exposed in the UI as "Tier B · Linux 代理 Claude Haiku", including a token/cost-per-call ledger at /api/ai-calls.
The /api/tasks/run endpoint with a free-form shell.command package — an arbitrary-shell primitive against every enrolled handset, once authenticated.

We are not the first to observe Chinese-market "云控平台" (cloud control platform) tooling; the category has been discussed for years in Chinese-language forums, in app-store abuse research, and in platform trust-and-safety writeups. What this report contributes is a concrete, named, currently-live instance, with its feature surface documented from the static code the panel serves to unauthenticated visitors. If you have prior reporting on the "TKFleet" brand, the com.yyds.auto family, or the 47.251.111[.]98 operator, please reach out and we'll update this post and credit the earlier source.

Infrastructure: 47.251.111.98:8080

Property	Value
IP	`47.251.111[.]98`
Hosting	Alibaba Cloud LLC — `OrgId: AL-3`, `Country: US`
Abuse contacts	`abuse@alibaba-inc.com`, `intl-abuse@list.alibaba-inc.com`
Ports observed	22/tcp (SSH), 80/tcp (empty), 443/tcp, 8080/tcp (the panel)
Server banner (8080)	`SimpleHTTP/0.6 Python/3.12.3`
Panel URL	`hxxp://47.251.111[.]98:8080/`
Panel size	142,919 bytes (single HTML page)
UI language	Simplified Chinese (`<html lang="zh-CN">`)
Font stack tell	`"PingFang SC","Microsoft YaHei"` — PRC operator defaults
Metrics endpoint	`hxxp://47.251.111[.]98:8080/metrics` — world-readable

The choice of Alibaba Cloud's US region is likely not accidental: the panel targets US/EU consumer platforms (Spotify, YouTube, Instagram, Facebook, X, TikTok) and benefits from egressing over US transit. The operator is running a SimpleHTTPServer — Python's built-in development-only web server — in production, which is both a classic low-effort-operator tell and an indication they have a separate upstream process handling the authenticated API.

Shodan's tag set for this IP (cloud, proxy) plus the externally-visible port 3128 suggests the same host may also be running a Squid-style open proxy, consistent with other commercial Chinese-bot-farm operators who bundle SOCKS/HTTP proxy resale with engagement-farming services.

Live-use metrics

Pulled from /metrics at the time of writing:

rpa_devices_total 2
rpa_devices_online 2
rpa_http_requests_total 861
rpa_http_errors_total 0
rpa_screenshots_total 45
rpa_tasks_dispatched_total 0
rpa_tasks_running 4
rpa_tasks_success_1h 0
rpa_tasks_failed_1h 0

Only two devices are enrolled right now — this is almost certainly the operator's own internal staging/test rig, not the production 5,000-device fleet the UI is sized for. But it is not idle: rpa_http_requests_total climbs steadily (+40 in ~15 minutes while this report was being drafted), which means operators are actively driving the UI. The rpa_screenshots_total = 45 counter ticks with the live-mirror feature described below.

The Panel: "TKFleet · 云控平台 · v8.1-wake2"

The HTML stamps its product identity three times:

<title>AndroidRPA · 云控平台 · v8.1-wake2</title>
...
<h1>TKFleet 云控平台</h1>
...
<div class="logo"><span class="logo-dot"></span> AndroidRPA</div>

"云控平台" translates to "cloud control platform" — the Chinese-ecosystem term of art for large-scale cloud-managed Android device farms, widely used by legitimate QA testing labs but also the dominant marketing term among grey-market account-farming and fake-engagement operators.

"TKFleet" is strongly suggestive of TikTok fleet — the TK prefix tracks with how most Chinese-SEO and grey-hat developer tooling abbreviates TikTok internally. The version string v8.1-wake2 implies a mature codebase with at least eight major revisions, and internal code comments refer to "W2/W5" audit modules, suggesting wake2 = "W2", i.e. a specific sub-version of the 8.1 branch.

The left nav is organized into four groups:

(top) 🏠 首页 · 📱 设备矩阵 (Home · Device Matrix)
活动中心 (Activity Center) · 🌱 养号池 · 🎯 定向活动 · ⏰ 定时任务 (Farming Pools · Targeted Campaigns · Scheduled Tasks)
系统 (System) · 📈 监控大盘 · ⚠️ 问题中心 (Monitoring Dashboard · Issue Center)
V8.1 审计 (V8.1 Audit) · 📊 设备状态 · 🔒 隔离设备 · 🤖 AI 调用 (Device States · Quarantine · AI Calls)

Every section below maps to one of these.

Target Platforms and Per-Platform Action Catalogs

The panel's PLATFORMS constant enumerates the six target platforms directly:

const PLATFORMS = [
  {id:'spotify',   icon:'🎵', name:'Spotify'},
  {id:'youtube',   icon:'📺', name:'YouTube'},
  {id:'tiktok',    icon:'🎬', name:'TikTok'},
  {id:'instagram', icon:'📷', name:'Instagram'},
  {id:'facebook',  icon:'👥', name:'Facebook'},
  {id:'x',         icon:'𝕏',  name:'X'},
];

And the per-platform action catalog — the actions each enrolled device can perform during a farming-pool session — is explicit, with default probability weights:

Platform	Actions (internal ID · Chinese label · default %)
Spotify	`browse_home` 刷首页 60% · `search_artist` 搜索歌手 40% · `play_playlist` 播放歌单 100% · `like_song` 点赞 50% · `follow_artist` 关注艺人 5%
YouTube	`browse_feed` 刷首页 70% · `search_video` 搜索视频 40% · `watch_video` 看视频 100% · `like_video` 点赞 40% · `subscribe` 订阅 10%
TikTok	`browse_fyp` 刷 FYP 100% · `like_video` 点赞 30% · `follow_user` 关注 5% · `comment` 评论 3%
Instagram	`browse_feed` 刷首页 80% · `like_post` 点赞 40% · `browse_reels` 刷 Reels 50%
Facebook	`browse_feed` 刷首页 100% · `like_post` 点赞 30%
X	`browse_timeline` 刷时间线 100% · `like_tweet` 点赞 40% · `retweet` 转推 8%

Three things to note.

Spotify's play_playlist at 100% and TikTok's browse_fyp at 100% are the load-bearing actions. The panel defaults make clear the operator's primary revenue model is paid-stream inflation on Spotify and FYP-view inflation on TikTok. Subscribe/follow actions are deliberately rare (5–10%) because platforms weight follower-graph growth more aggressively for ban signals than passive content consumption.
The comment action on TikTok defaults to 3% — comments are high-risk for the account but generate outsized engagement signal, which is why the ratio is kept deliberately low.
All probabilities are operator-editable, per-pool, in the campaign wizard — so this is just the built-in default profile of what a "well-behaved" farmed account looks like on each platform.

Execution Backends: HID, Accessibility, Shizuku

This is the single most revealing piece of the panel. Four execution backends are offered as a first-class per-device dropdown:

const BACKENDS = [
  {id:'auto',    name:'自动选择', icon:'⚙️'},
  {id:'hid',     name:'HID 外挂', icon:'🔌'},
  {id:'a11y',    name:'无障碍',   icon:'♿'},
  {id:'shizuku', name:'Shizuku',  icon:'🛡️'},
];

Each backend corresponds to a different way to automate the phone without being detected as automation:

HID 外挂 (HID hardware injection, 🔌) — an external USB/OTG microcontroller emulating a USB HID keyboard/mouse, physically plugged into the handset. Because input events arrive through the standard USB-HID stack, they are indistinguishable from a human plugging in a Bluetooth keyboard. Of the four, HID is the hardest for an app to fingerprint, because the detection surface (InputDevice.isVirtual(), getSources()) reports a legitimate USB input peripheral. Its existence as a named backend strongly implies a physical rack of 5,000 handsets, each cabled to a USB-HID injector board.
无障碍 (Accessibility / a11y, ♿) — the classic Android bot-framework trick of abusing AccessibilityService to read the UI tree and dispatch AccessibilityAction.ACTION_CLICK events. Low setup cost, high detection risk — platforms like TikTok and Instagram have had accessibility-fingerprint checks in production for years.
Shizuku (🛡️) — a legitimate open-source tool that lets unprivileged apps hold android.permission.INJECT_EVENTS via an adb-started daemon. Gives you real injected input events without rooting the phone, and is a common choice in grey-market tooling because the fingerprint is cleaner than a11y and the setup is cheaper than HID.
auto (⚙️) — the panel's runtime picks among the first three based on the /api/backend/health readings, which fall back in a default priority the UI also exposes.

The panel also shows a per-backend health rate on the home dashboard (/api/backend/health, healthy_rate) and a batch "switch backend" bulk action on the device list, suggesting the operator routinely A/B's backends across the fleet to find whichever is least-detected for a given platform × device-model combination.

Operations Model: Farming Pools vs Targeted Campaigns

The panel separates workloads into three layers:

1. 养号池 (Farming Pools) — "keep the account alive"

Long-running, randomized, low-intensity activity designed to make each account look human and avoid risk-control flagging. From the in-app description:

🌱 养号池 · 长期运行 · 让账号"活着"不被风控

(Loosely: "Farming Pool · long-running · keep accounts 'alive' so they don't get risk-controlled.")

A pool is configured via a six-step wizard — 选平台 → 基本信息 → 标签 + 账号池 → 行为配方 → 时间 + 风控 → 预览 + 启动 — that pins down sessions/day, minutes/session, per-action probabilities, allowed hour window (default 7:00–23:00 in the account's local time), and cooldowns. Default cooldown values in the code:

cooldown_account_s: 7200 (two hours between sessions on the same account)
cooldown_device_s: 900 (fifteen minutes between sessions on the same phone)
daily_limit_account: 3 (three sessions/day maximum per account)

These are deliberately set below the known fraud-detection thresholds for each platform.

2. 定向活动 (Targeted Campaigns) — "batch execute against a specific target"

One-shot, high-intensity runs. Step 2 of the campaign wizard takes a JSON params object:

{"url":"https://youtu.be/...","dwell_sec":30}

…and Step 3 lets the operator select cohorts by group label and by per-platform login status, then pick a cohort size (default 100 devices).

A preview call (/api/campaigns/preview) tells the operator:

匹配在线设备: N 台 · 可用账号: M 个 ("Matched online devices: N · available accounts: M")

…before confirming. At Step 4 the operator sets start time, span, and per-campaign rate controls: max dispatches/hour, per-account cooldown, per-device cooldown, and a daily per-account cap. All of these are separate from the farming-pool defaults and override them for the duration of a campaign.

3. 定时任务 (Scheduled Tasks) — "trigger layer"

Standard 5-field cron expressions (minute hour day month weekday) that trigger either a farming pool or a targeted campaign on schedule. The UI shows the example 0 7 * * * with a Chinese annotation ("每天 7 点" — "every day at 7 AM").

The Rick Astley Tell

The hardcoded placeholder text in Step 2 of the targeted-campaign wizard is this:

<input class="inp" id="cw-name" ... placeholder="例如 Rick Astley 订阅 × 500">

"e.g. Rick Astley subscribe × 500"

That's the operator's own example of a real use case: 500 Android handsets, logged into 500 YouTube accounts, all instructed to subscribe to Rick Astley's channel in a single batch, dispersed over a 4-hour window with a 60-second initial jitter. It is, functionally, the business model of the platform in eleven characters.

(Whoever wrote the placeholder also has a sense of humor.)

The default schedule_kind is now · 分散 60s — "start now, spread over 60 seconds" — which confirms that the platform's business rhythm is pay-to-win engagement-spam with a thin randomization layer on top.

AI Layer: Claude Haiku as Fallback Brain

Under the V8.1 审计 → 🤖 AI 调用 nav item is a dashboard labeled:

🤖 AI 调用 · Tier B 视觉导航 · Linux 代理 Claude Haiku (mock if no ANTHROPIC_API_KEY)

The dashboard exposes:

24-hour call volume
24-hour cost in USD
24-hour token count
Success rate
Success / fail counts
Per-call table: ts · device_uid · goal · decision · fail_category · tokens · cost_usd · success · reason

In context, "Tier B" means the fallback automation tier. Tier A is the deterministic XPath/selector path (the "happy path" for scripted automations). When Tier A fails — UI changed, an unexpected popup appeared, a login prompt surfaced, etc. — the device falls back to Tier B, which sends a screenshot plus a natural-language goal to Claude Haiku and lets the model decide the next tap/swipe.

The "Linux 代理" annotation ("Linux proxy/agent") suggests each phone's com.yyds.auto companion ships screenshots to a Linux-side process that calls the Anthropic API, gets a structured decision back (tap (x,y) / swipe / type / back / etc.), and forwards it to whichever backend (HID / a11y / Shizuku) is currently bound.

Two things worth noting:

The dashboard explicitly shows per-call USD cost, which means the operator has a working ANTHROPIC_API_KEY and is being billed for real Claude Haiku usage. The "mock if no ANTHROPIC_API_KEY" note is a developer-mode fallback, not the production behavior.
Haiku is a deliberate model choice. The operator is optimizing for cost-per-decision across a 5,000-device fleet, so using Sonnet or Opus for every screen-parse would be prohibitive. Haiku's sub-cent-per-call economics are precisely why it's viable as the visual-navigation brain of a bot farm.

This is one concrete case of a consumer-platform bot farm appearing to use a commercial LLM as its cognitive layer. For platform trust-and-safety teams, if "LLM drives the UI decisions" is not yet in the abuse-vector model, it may be worth adding.

Device-Side APK: com.yyds.auto (The Fake Tencent Package)

The device-restart bulk action on the device matrix page gives us the Android package name and the launcher activity directly:

params:{cmd:'am force-stop com.yyds.auto && sleep 1 && am start -n com.yyds.auto/com.tencent.yyds.MainActivity'}

Package name: com.yyds.auto
Launcher activity: com.tencent.yyds.MainActivity

Two tells here:

yyds is internet-slang shorthand for "永远的神" ("eternal god") — extremely common PRC gamer/slang shorthand and a well-worn naming prefix for grey-market Chinese Android tooling.
The activity is intentionally namespaced under com.tencent.yyds despite Tencent having nothing to do with this software. This is namespace-squatting to make the running process look, to anyone casually inspecting adb shell ps or dumpsys activity top, like a legitimate Tencent service. Android does not enforce that the activity's class package match the APK's package — a common blind spot that legitimate developers don't exploit but malware and grey-tooling vendors routinely do.

The fact that the control panel uses adb-style shell commands (am force-stop, am start) to restart the app means every enrolled device has an active adb or adb-equivalent channel back to the Linux controller — consistent with the HID/Shizuku backend choices above, both of which typically depend on an adb-initiated daemon.

Risk-Control Evasion Built Into The UI

The login-status model for every account on every device is a four-state machine — directly from the UI strings:

正常 → 未登录 → 标记为风控 → 标记为被封

(Normal → Logged-out → Flagged [risk-controlled] → Banned)

Each state is stored per-device-per-platform, with an evidence field and a method field indicating how the automation detected the state change. The panel's problem-center (⚠️ 问题中心) has a built-in standard-operating-procedure (SOP) lookup with canned responses:

const sopMap = {
  'devices_offline':  { sop:'ops/runbooks/01-device-offline.md', hint:'检查机架电源、网络、adb forward' },
  'campaign_failed':  { sop:'ops/runbooks/05-campaign-fail.md', hint:'查看 drift 聚类 · 多数是脚本盲点' },
  'task_timeouts':    { sop:'ops/runbooks/03-task-timeout.md', hint:'bridge 掉线或脚本卡死 · 重启 APK' },
  'content_stale':    { sop:'—', hint:'内容池轮换' },
};

Unpacking:

devices_offline · 检查机架电源、网络、adb forward — "check rack power, network, adb forward". Confirms the 5,000-device assumption is not figurative: the operator refers to physical racks of handsets and recommends adb forward as the first debug step.
campaign_failed · 查看 drift 聚类 · 多数是脚本盲点 — "look at the drift cluster · mostly script blind spots". The panel has a concept of "drift" — when a scripted action produced an unexpected UI state. The mitigation is cluster-analyzing drift signatures to find which UI-path changed, then updating the script.
task_timeouts · bridge 掉线或脚本卡死 — "bridge disconnected or script stuck". A bridge process sits between the controller and each device; reliability engineering focuses on bridge uptime.
content_stale · 内容池轮换 — "content pool rotation". There's a content pool (scripts, comments, search queries) that must be rotated to avoid pattern-matching detection.

Every visible design decision in the panel is an anti-detection measure. This isn't a tool that has anti-detection features — anti-detection is the product.

Live Screen Mirror and Arbitrary Shell

Two endpoints worth calling out specifically.

`/api/device/<uid>/screenshot` — 1–1.5 Hz live mirror

const r = await fetch(`/api/device/${encodeURIComponent(uid)}/screenshot`,
  { headers: { 'Authorization': 'Bearer ' + API.token } });
...
img.src = 'data:image/jpeg;base64,' + data.jpeg_b64;

Every enrolled device exposes a 1–1.5 Hz JPEG screenshot stream to any authenticated operator. The UI starts it on drawer open (startLiveMirror(uid, ...)) and stops it on close, with a 5-error-strikes-out auto-disconnect. rpa_screenshots_total 45 in /metrics confirms the endpoint has been exercised during this deployment.

`/api/tasks/run` — `shell.command` arbitrary shell

await api('/api/tasks/run', {method:'POST', body:{
  device_uid: uid, package:'shell.command',
  params:{cmd:'echo ok'}
}});

The panel's own built-in "self-test" bulk action calls /api/tasks/run with package:'shell.command' and a free-form params.cmd. There is no allowlist on the client side. Any authenticated session can execute arbitrary shell against every enrolled device. Combined with the adb-equivalent privilege level all four backends imply, this is post-exploitation-grade remote command execution on every handset the panel manages — whether or not the devices' nominal owners (if any) consent.

(If the 5,000 handsets are a physical rack the operator owns, this is unremarkable — it's their kit. If any of them are "rented" from third parties — which is a standard model in the Chinese engagement-farming ecosystem — it becomes a much more interesting question.)

V8.1 Audit Layer: 6-State Device Lifecycle

The V8.1 审计 nav group exposes a lifecycle-state model with its own dedicated API surface at /api/devices/states, /api/devices/<uid>/transitions, and /api/quarantine.

Six states and their UI colors:

State	Color	Meaning
`PROVISIONING`	gray `#6b7280`	New device being enrolled
`ONLINE`	green `#10b981`	Healthy, taking work
`DEGRADED`	amber `#f59e0b`	Partially healthy
`OFFLINE`	gray `#9ca3af`	Unreachable
`QUARANTINED`	red `#ef4444`	Suspended pending ops review
`RETIRED`	dark gray `#374151`	Permanently decommissioned

Transitions are stored with from_state, to_state, cause, actor, and a JSON evidence blob. The panel's device-details page describes the design intent in one line:

公理一：设备能力事实(端上报) + 云端派生生命周期

Axiom 1: device-capability facts (reported from the handset) + cloud-derived lifecycle.

Translation: device-reported capabilities (CPU, battery, online-ness) are treated as facts that the cloud uses to derive the lifecycle state. This is very intentional engineering — a level of operational maturity that is notable for a grey-market product — and is consistent with a team that has been running this platform long enough to need a formal reliability model.

IOCs

Infrastructure

Type	Value	Notes
IPv4	`47.251.111[.]98`	Alibaba Cloud LLC (US) — TKFleet / AndroidRPA panel
Port	`8080/tcp`	HTTP — TKFleet panel
Port	`22/tcp`	SSH
Port	`443/tcp`	HTTPS
Port	`3128/tcp`	HTTP-proxy (per Shodan tag)
URL	`hxxp://47.251.111[.]98:8080/`	Login screen
URL	`hxxp://47.251.111[.]98:8080/metrics`	Prometheus metrics, world-readable
ASN / Org	`Alibaba Cloud LLC`	`OrgId: AL-3`

Product identifiers

Type	Value
Product name	`TKFleet 云控平台`
HTML title	`AndroidRPA · 云控平台 · v8.1-wake2`
Sub-version	`wake2` (internal "W2" audit module)
Server banner	`SimpleHTTP/0.6 Python/3.12.3`
UI language	`zh-CN`

Android companion APK

Type	Value
Package name	`com.yyds.auto`
Launcher activity	`com.tencent.yyds.MainActivity` (impersonating Tencent namespace)

Behavioral / network indicators

Outbound calls from panel host to Anthropic API (Claude Haiku) for vision-navigation decisions.
Per-device JPEG streaming back to panel host at ~1 Hz.
adb forward-style reverse channels from each handset to the panel host.
Six-phase device lifecycle with transition-evidence telemetry.

Target platforms (engagement fraud subjects)

Spotify — playlist plays, likes, follows
YouTube — views, likes, subscribes
TikTok — FYP views, likes, follows, comments
Instagram — feed browses, likes, reels plays
Facebook — feed browses, likes
X (Twitter) — timeline browses, likes, retweets

MITRE ATT&CK Mapping (Android-adjacent)

Tactic	Technique	Relevance
T1437.001	Application Layer Protocol: Web Protocols	HTTP/JSON control channel to panel
T1444	Masquerading as Legitimate Application	`com.tencent.yyds.MainActivity` impersonates Tencent
T1626	Abuse Elevation Control Mechanism	Shizuku / Accessibility-service abuse for input injection
T1417.001	Input Capture: Keylogging (inverted — injection)	HID hardware injection
T1630.002	Indicator Removal on Host: File Deletion (content pool rotation)	"内容池轮换" SOP
T1628.001	Hide Artifacts: Suppress Application Icon	(likely — standard for `com.yyds.auto`-style tooling)
T1633.001	Virtualization / Sandbox Evasion — System Checks	Risk-control cooldowns that mimic human cadence
T1562	Impair Defenses — Time-Based (human-like cadence)	Per-account daily limits, 2h cooldowns, 7–23h windows

ATT&CK's Enterprise matrix arguably under-captures engagement-fraud operations. Coverage in the FS-ISAC Financial Crime Kill Chain and in TrustPKG / [Social Media Fraud Attack Framework] taxonomies may be more appropriate.

Recommendations

For the targeted platforms (Spotify / YouTube / TikTok / Meta / X)

Assume the 6-state lifecycle and 4-state-per-platform login machine are already tuned against your current risk-control thresholds. The panel's cooldown defaults (7200s account, 900s device, 3 sessions/day) are almost certainly the result of measurement, not guesswork.
Fingerprint HID-injected input. Of the four backends the panel exposes, HID is explicitly the hardest to distinguish from legitimate human input. Adding signal on InputDevice age, USB vendor/product patterns for known HID-injector boards (e.g., Arduino Pro Micro, Raspberry Pi Pico acting as HID), and input-event inter-arrival distributions is likely to be the highest-leverage single hardening move.
Detect com.yyds.auto-family packages via both the package name and the Tencent-namespace masquerade. In particular, MainActivity classes in com.tencent.* namespaces that ship inside an APK whose applicationId is not com.tencent.* are a high-precision signal.
Baseline on Claude Haiku usage from high-engagement accounts. The operator described here is driving Claude Haiku with per-device screen state. Accounts whose decision latency jumps when UI elements change in unexpected ways — a signature of "screenshot → LLM → decide → act" — are a novel signal that may not be in current anti-abuse model features.

For Alibaba Cloud abuse

The panel is plaintext-HTTP on 8080 from 47.251.111[.]98, has no authentication on /metrics, openly advertises itself as a farming/campaign platform in Mandarin, and hosts an arbitrary-shell endpoint against a 5,000-device fleet.
Abuse contact: abuse@alibaba-inc.com (per ARIN rwhois).

For defenders in general

The cognitive layer is worth considering. This is one case of a commercial LLM being used as the runtime brain of a consumer-platform automation stack. Anti-abuse roadmaps may want to include "operator has an LLM driving the UI decisions" as a modeled scenario.
Physical device farms remain relevant. Emulator-detection alone does not cover this class of activity; HID-injection against real handsets sidesteps most published "detect the emulator" techniques.

Appendix A — Notable Strings

管理 5000 台真机 — "Manage 5000 real handsets" (device-matrix page subtitle)
Tier B 视觉导航 · Linux 代理 Claude Haiku (mock if no ANTHROPIC_API_KEY) — AI-call page subtitle
让账号"活着"不被风控 — "Keep accounts 'alive', not risk-controlled" (farming-pool page subtitle)
触发层 · 按时间规则启动养号池 / 定向活动 — "Trigger layer · run farming-pools / targeted-campaigns on time rules" (scheduled-tasks subtitle)
公理一：设备能力事实(端上报) + 云端派生生命周期 — "Axiom 1: device-capability facts + cloud-derived lifecycle" (device-states subtitle)
检查机架电源、网络、adb forward — "Check rack power, network, adb forward" (devices-offline SOP)
例如 Rick Astley 订阅 × 500 — "e.g., Rick Astley subscribe × 500" (targeted-campaign name placeholder)

Appendix B — Observed API Surface (from the panel's static HTML/JS)

Method	Path	Purpose
POST	`/api/auth/login`	Operator login (`{username, password}` → Bearer token)
GET	`/api/devices`	Device list
POST	`/api/devices/<uid>/update`	Update group, backend, or enabled
POST	`/api/devices/<uid>/platform-login`	Mark login state per platform
POST	`/api/devices/<uid>/detect-logins`	Dispatch per-device login-detection task
GET	`/api/devices/states`	6-state lifecycle distribution
GET	`/api/devices/<uid>/transitions`	Transition history
GET	`/api/pools` / POST `/api/pools/create` / POST `/api/pools/<id>/update`	Farming pool CRUD
GET	`/api/campaigns` / `/api/campaigns/templates` / POST `/api/campaigns/preview`	Campaign list, templates, cohort preview
POST	`/api/campaigns/<id>/{pause,resume,cancel}`	Campaign controls
GET / POST	`/api/schedules`	Scheduled tasks (cron)
GET	`/api/issues` / POST `/api/issues/<id>/resolve`	Issue center
GET	`/api/backend/health`	Per-backend health rate
GET	`/api/quarantine`	Quarantined devices
GET	`/api/ai-calls`	Claude Haiku call ledger
GET	`/api/device/<uid>/screenshot`	1 Hz JPEG live mirror
POST	`/api/tasks/run`	Arbitrary shell / action dispatch

Investigation conducted and report prepared by Breakglass Intelligence, from a tip by @justwanttoQ1. If you have prior or corroborating research — particularly on the "TKFleet" brand, the com.yyds.auto APK family, or the 47.251.111[.]98 operator — please reach out and we'll update and credit. Contact: reply or DM @BreakGlassIntel on X.

TKFleet · AndroidRPA v8.1-wake2: A Chinese-Language Bot Farm Control Panel Running on Alibaba Cloud US

TL;DR

What This Report Adds to the Public Record

Infrastructure: 47.251.111.98:8080

Live-use metrics

The Panel: "TKFleet · 云控平台 · v8.1-wake2"

Sidebar structure

Target Platforms and Per-Platform Action Catalogs

Execution Backends: HID, Accessibility, Shizuku

Operations Model: Farming Pools vs Targeted Campaigns

1. 养号池 (Farming Pools) — "keep the account alive"

2. 定向活动 (Targeted Campaigns) — "batch execute against a specific target"

3. 定时任务 (Scheduled Tasks) — "trigger layer"

The Rick Astley Tell

AI Layer: Claude Haiku as Fallback Brain

Device-Side APK: com.yyds.auto (The Fake Tencent Package)

Risk-Control Evasion Built Into The UI

Live Screen Mirror and Arbitrary Shell

/api/device/<uid>/screenshot — 1–1.5 Hz live mirror

/api/tasks/run — shell.command arbitrary shell

V8.1 Audit Layer: 6-State Device Lifecycle

IOCs

Infrastructure

Product identifiers

Android companion APK

Behavioral / network indicators

Target platforms (engagement fraud subjects)

MITRE ATT&CK Mapping (Android-adjacent)

Recommendations

For the targeted platforms (Spotify / YouTube / TikTok / Meta / X)

For Alibaba Cloud abuse

For defenders in general

Appendix A — Notable Strings

Appendix B — Observed API Surface (from the panel's static HTML/JS)

`/api/device/<uid>/screenshot` — 1–1.5 Hz live mirror

`/api/tasks/run` — `shell.command` arbitrary shell