Security researcher. Founder of VULONE. Attribution across the underground.
Walless Al Essa

A China-Linked Operator Used AI Agents to Attack Governments Across Asia

How one operator ran 66 AI-driven intrusions against governments and companies across Asia from a single server that sat open to the internet for two weeks.

Over sixteen days, a single operator ran sixty-six separate operations against government and industry targets across Asia and beyond, using LLM agents dispatched from one server. The target list included Vietnam's defence and public-security ministries, Taiwan's Legislative Yuan, Indonesia's State Intelligence Agency, India's CDAC, and a long list of payments, retail and SaaS companies. Forty-eight of the sixty-six reached some level of access. For the last two weeks of its life, the whole operation was sitting open to the internet.

Executive summary

Between 29 September and 15 October 2026, a server at 202.61.139[.]15 (AS152194, CTG Server Ltd, Singapore) served its entire /tmp directory over HTTP on port 9000, with no authentication. That directory belonged to an autonomous exploitation platform built on the open-source Cairn framework. We retrieved the exposed files and, under authorization, accessed the host. We preserved the operation's data directory, the relevant parts of the host filesystem, and its container storage: 16.4 GB of verified, hashed archives.

What the data showed was an AI-driven offensive operation larger than anything we had previously seen attributed to a single operator:

  • 66 active projects against named organizations, run between 24 September and 14 October. 48 reached at least session-level access: 6 at root or SYSTEM, 39 at non-root command execution, 3 at webshell stage.
  • Targets included government systems in Vietnam, Taiwan, Indonesia and India, among them Vietnam's Ministry of Defence and Ministry of Public Security, Taiwan's Legislative Yuan and Ministry of Justice-linked systems, Indonesia's State Intelligence Agency, and India's Centre for Development of Advanced Computing, alongside companies in payments, retail, travel, hosting and SaaS: Every8D, Huffy and its sister bicycle brands, China Airlines, Air India, Juspay, Hertz, PayMore, TotalAV, PC Protect, Fluidstack and others.
  • The platform ran 116 unique worker containers and logged roughly 230,000 dispatcher events over twelve days, consuming an estimated 36.7 billion LLM tokens through a single gateway key.
  • The operator funded the compute through six subscription accounts and a farm of 16 daily-checked CodeBuddy identities, a cost-avoidance pattern we had not seen documented before.
  • The attribution evidence points to a China-linked, Chinese-speaking, financially motivated operator. We found no evidence of state sponsorship in the artifacts we examined. The operation is not attributable to the previously reported "SOUL" campaign, though it shares the same exploitation engine. The strongest route to a name runs through the billing and identity records behind the operator's LLM accounts (see §5.2 and §9).

The open directory was the most visible of several mistakes. The platform's own records (task databases, logs, shell history) documented much of the operation in plain text.

1. Background and initial discovery

The investigation began with the IP address alone. A Python HTTP server, started on 29 September at 22:13 UTC, was serving the host's /tmp directory:

python3 -m http.server 9000 --directory /tmp
The exposed /tmp directory listing served over HTTP on port 9000, no authentication

Figure 1. The operator's /tmp directory, served to the open internet on port 9000 with no authentication, no IP restriction, and no rate limiting. This listing is where the investigation began.

There was no authentication, no IP restriction, and no rate limiting. The same directory was mirrored on a second address the operator controlled, 202.61.139[.]137; both served the identical listing under the same banner (SimpleHTTP/0.6 Python/3.12.3). A separate set of services tied the two addresses to one host: the operator's custom Python TLS listeners, kept for SNI and payload logging, ran on ports 443, 8443 and 4443 of the primary IP and on 443 of the second, and all presented the same self-signed certificate (CN=202.61.139.15, valid only for 3 to 5 October, SHA256 93:17:8D:…41:FF, full value in §8). The port-9000 server itself is plain HTTP; the certificate came from those listeners, and its appearance on both addresses links them. That certificate is the closest thing to an identifier the operator produced.

The exposed directory contained 339 files, which we preserved and hashed (the SHA256 manifest is held with the case record). It included exploit kits, host reconnaissance and credential-scraping scripts, watchdog scripts, log files, and configuration fragments. Within the first hour it was clear this was not a lab or a demo environment. The files referenced live victim hosts, live credentials, and a running campaign.

2. What the exposure was

A short inventory of the exposed directory, since it frames what follows:

  • Exploit tooling: i051_shock_rce.py (a Shellshock-over-SMTP kit), MssqlProbe.java, sakip_i061.tgz, and per-engagement scripts and probes.
  • Credential handling: cred_scan.py, config_cred_scan.py, scripts written to walk victim filesystems for secrets.
  • Platform maintenance: cairn_guard.sh, cairn_disk_guard.sh, and orchestration helpers whose comments are in Simplified Chinese.
  • Operational logs: HTTP access logs, listener captures, and per-task evidence directories, some recording the results of successful intrusions.

The directory was live, and its access log was still being written as we examined it. Between 29 September and 15 October it received more than 753,000 requests from 19,307 unique IP addresses: cloud scrapers, Tor exit nodes, and automated request loops from datacenters on three continents. During our own collection, at least one other party was downloading the same database files. For the last two weeks of its life, this operation was not a secret.

3. Accessing the host

How the host was accessed is a detail we are not disclosing. The platform was built to hide its work from the systems it attacked, and there is no reason to publish the way in. Access and collection were carried out under authorization. What matters here is what the data showed.

The host was treated as an evidence source from the first minute rather than a place to explore. Root's shell history held reverse-shell handlers, a test of a mass-mailing script, exploit runs against specific victims, and repeated manual checks of the platform's task interface. The host is an Ubuntu VM (VM-Z4bLOIWlNO, kernel 6.8.0) that had been up for 21 days.

Two things were immediately clear. First, the operator was careless where it mattered: his exfiltration endpoints were hardcoded throughout his tooling, so every system his kit touched was handed the address of his command-and-control server. Second, the platform's own records documented the operation in plain text, in enough detail to reconstruct weeks of activity.

4. Collection and preservation

Over the following day we preserved the operation's data, the relevant parts of the host filesystem, and its container storage. This was a targeted collection, not a bit-for-bit disk image. We took what the case requires and what can be verified, and we note that distinction. In total:

  • 1.98 GB, /data/cairn-chat: the platform's working data, including graphs, contexts, and 11,180 AI session logs across 42 projects (74,756 files).
  • 265 MB, selected host filesystem areas (/opt, /root, /var/log, /etc, /home, /tmp): account pools, provider configurations, SSH material, authentication records, system logs, caches (12,605 files).
  • 14.16 GB, container evidence: a compressed capture of Docker overlay layers, 1,535,238 files in total, including roughly 1.27 million files from task evidence directories that had been deleted from the host and recovered from the container layers (44 GB uncompressed).

Every archive was verified (gzip integrity), hashed (SHA256), and timestamped. Pre-modification copies of all host log files were retained before any interaction beyond reading, and where interaction was unavoidable it was documented. The evidence was handled on the assumption that it may need to stand up in court.

5. The platform: Cairn and its deployment

The server is an instance of Cairn, an open-source autonomous exploitation framework: an operator defines a target and an objective, and the framework drives LLM-based agents, each in its own Kali-based container, to attempt the objective.

For the record: Cairn is public software, with a public container image and several hundred forks. Using a tool does not identify its author, and nothing in this investigation connects the maintainers of that project to the operator. What is specific to this operator is everything built around the framework (the orchestration scripts, the account infrastructure, the operational decisions) described below.

5.1 Architecture and scale

At a high level, the platform looked like this: one dispatcher on the VPS drove a fleet of short-lived Kali worker containers, each talking to an upstream LLM gateway, with all state kept in a single SQLite database and completed work archived to disk. The same box also, fatally, exposed its scratch directory on port 9000.

Cairn deployment diagram

Figure 2. The Cairn deployment. A single dispatcher schedules disposable worker containers against named projects, routes their reasoning through one LLM gateway, and records everything in a SQLite "brain." The port-9000 file server on the left-hand box is what made the whole thing visible.

  • Workers. Kali-based containers running with host networking, dispatched per project. The operator ran up to 116 workers over the operation's lifetime, with dozens active at once.
  • Dispatcher. The dispatch log contains 229,828 entries between 24 September and 6 October, roughly one dispatch event every four and a half seconds, sustained for twelve days.
  • Watchdogs. Two cron scripts keep the platform running. cairn_guard.sh restarts the dispatcher when its memory footprint approaches the host's limit; a comment in the script records an earlier incident in which the dispatcher grew to 12 GB on a 16 GB host and OOM-killed the system. cairn_disk_guard.sh sweeps worker temp space every fifteen minutes; its comments are in Simplified Chinese, and the directories it preserves are labelled 攻击证据, "attack evidence."
  • Egress. The operator used the server's second IP, 202.61.139[.]137, as an alternate source address for tests against target infrastructure, visible in both task logs and dispatch configuration.

5.2 The AI backend

Task workers route through a local gateway to a single model: global:deepseek-v4.1-flash. One gateway key recorded 36,771,234,882 tokens processed. The account pool behind it is worth describing in full, because it is the most distinctive part of the setup:

  • Six subscription accounts (monthly LLM service plans), registered in a batch within days of each other in late September. At least one was already in arrears (a balance of −$147.48) when we collected the records.
  • A CodeBuddy account farm. A scheduled task checks in 16 distinct Gmail-based CodeBuddy identities every day, harvesting roughly 30 credits per identity per day, about 480 credits of free compute daily, fed into the exploitation pipeline.
  • Additional provider credentials for at least two other LLM services, used as fallbacks.

The account-pool software is third-party open-source, written to proxy and rotate CodeBuddy accounts; the operator adapted it rather than writing it. The identities and billing records behind the pool are, in our assessment, the single most promising identification route in this case, and have been referred accordingly (see §9).

5.3 How the operator directed the AI

The logs preserve the instructions the operator gave his agents. Several are worth quoting.

A typical project objective:

目标必须获取 webshell 或系统命令执行 (RCE),仅获取后台/应用权限不算完成

("The target must obtain a webshell or system command execution (RCE). Obtaining only admin panel or application access does not count as completion.")

Operator project objective requiring webshell or RCE, admin access alone does not count

Figure 3. The operator's standing definition of success, taken from the platform's own project configuration: a run only counts as complete once it reaches a webshell or command execution. Panel or application access alone was explicitly rejected.

Other notes direct the agents on tradecraft, for example, converting a working shell to POST-only command submission, so commands travel in request bodies rather than URLs and are less likely to show up in victim access logs. The operator also routinely told the platform, after a successful task, to clean up evidence directories and use innocuous filenames.

One standing rule stands out. Every dispatcher prompt template carries the same instruction, marked as the operation's 最高红线, its "highest red line." It governs everything sent to a target (URLs, headers, cookies, GET and POST bodies, SQL and command payloads) and every file written to a victim system, including scripts, webshells, temp files, filenames, even code comments: all of it must be pure English/ASCII, with Chinese characters and comments explicitly forbidden. The workers enforced the rule on themselves; session transcripts show agents checking that "the agent payloads are English/ASCII" and planning steps so that "only English ASCII" reaches the target. The operator built the platform so that, on the victim's side, the intrusions would read as English. Language signals left on a compromised host can therefore be manufactured, and defenders should weigh them accordingly.

This is not a fully autonomous actor, and it is not a human working by hand. It is a human setting objectives and constraints, with agents doing most of the enumeration, exploitation, and post-exploitation collection. The distinction matters for defenders: the volume and persistence of attempts against a given target reflect machine patience, not human stubbornness.

6. Operations: targets and results

The campaign ran as a series of batches over roughly three weeks, moving from government targets into fintech, airlines and retail, with a final payments-and-CDAC push just before the platform went quiet.

flowchart TB
  A["24 Sep — campaign starts<br/>SE Asia government batch (Vietnam, Indonesia)"]
  B["25 Sep — Taiwan state batch<br/>Legislature, Ministry of Justice, intelligence bureau"]
  C["26–30 Sep — fintech, airlines, cloud<br/>Every8D, Air India, Juspay, Fluidstack"]
  D["1–10 Oct — Vietnam round 2 + ecommerce sweep<br/>nso.gov.vn, moha.gov.vn, ~25 commerce sites"]
  E["14 Oct — final project created<br/>cdac.in (India)"]
  A --> B --> C --> D --> E
  X["29 Sep – 15 Oct — /tmp directory exposed on port 9000"]

Figure 4. Campaign timeline. The government work came first, then the move into money. The exposure window (bottom) ran almost the entire length of the operation.

The following summarizes the platform's records for its 66 active projects. A necessary caveat: the access claims below are recorded by the operator's own tooling. We corroborated the strongest cases against exfiltration logs and listener captures where those survived, but victim-side verification is a task for notifications and law enforcement, not for a blog post.

6.1 Access obtained

Of 66 projects, 48 reached at least session-level access: 6 at root or SYSTEM, 39 at non-root command execution, 3 at webshell stage. Ten were run to exhaustion without access, one lost previously held access, and seven were created but never started. The database shows project IDs running to 120 with 54 IDs absent entirely, deleted or renumbered history whose targets are unknown to us.

6.2 Government systems

  • Vietnam: mod.gov.vn (Ministry of Defence subdomain: root inside a Kubernetes pod, via an unauthenticated RBAC bypass and arbitrary file write); mps.gov.vn (Ministry of Public Security: command execution on an Oracle database host via PL/SQL injection); bocongan.gov.vn (webshell and command execution via an anonymous FTP write and MSSQL xp_cmdshell); nso.gov.vn (General Statistics Office: ViewState deserialization to a POST webshell); moha.gov.vn (root via a workflow-engine chain); dongnai.gov.vn (JBoss Seam EL injection, CVE-2010-1871, a 2010 vulnerability, still exploitable); hatinh.gov.vn (Directus schema SQL injection to OS execution); icomm.vn (internal NiFi reached through an SSRF proxy).
  • Taiwan: ly.gov.tw (Legislative Yuan law system: CGI command injection reaching execution as uid=2(daemon)); moj.gov.tw (Ministry of Justice subsidiary: unauthenticated file-manager upload to webshell); mjib.gov.tw (via a third-party vendor application on outdated CentOS).
  • Indonesia: bin.go.id (State Intelligence Agency: command execution through an SSRF chain, plus mailbox access to a government account).
  • India: cdac.in (Centre for Development of Advanced Computing): the operator's final project, opened on 14 October, succeeded through default admin/admin credentials on a WSO2 API Manager console.

The shape of this list matters on its own. A legislative body's legal-research system, a ministry of justice's investigative arm, a national intelligence agency, and two defence and public-security ministries are not ordinary targets; they are the profile of access that state intelligence services collect. Whatever the operator's motive, and the artifacts point to money, this victim set places the case squarely in the interest of national-security investigators in four countries.

6.3 Industry

  • Every8D (teamplus.com.tw), a Taiwanese bulk-messaging platform, and the most complete compromise in the set. The kit exploited Shellshock (CVE-2014-6271) over SMTP: the target's mail filtering inspected MAIL FROM and message data but not the RCPT TO envelope line, and the payload in the recipient field was passed by qmail into bash. The result was execution as uid=510(vpopmail) on a RHEL5-era mail gateway, followed by full host reconnaissance, Apache configuration theft, and recovery of an internal MSSQL credential, all exfiltrated in 118 events to a listener on the C2.
  • China Airlines (china-airlines.com), 1,001 logged facts of effort. The operator held a vendor JSP shell (uid=1007) and lost it; our checks confirm the page is dead. His notes indicate attempts to reach cargo-related systems.
  • Air India (airindia.com), unauthenticated Java deserialization on the iCargo cargo system, leading to webshell and command execution.
  • Payments and retail: juspay.in (Euler merchant session to command execution); mysmartmove.com (admin JWT and an arbitrary-execution endpoint on a payment automation API); paymore.com (franchise-to-superadmin privilege bypass on Windows, POS session data, a Shopify token); dosfarma.com (Magento StyleSmuggler chain from file read to root); pcprotect.com; totalav.com (a hand-built PHP object-injection chain via Monolog); fortunecoins.com; theograce.com; paulandshark.com; stellarinfo.com; harddiskdirect.com; budypay.com; livegoodinc.com; bokla.me; johnnywas.com (ASP.NET webshell, machine keys, and database credentials); postable.com (a V8 issue in a Lambda-based card renderer); hertz.com (command execution as uid=1100 on a WebFOCUS server); trymiamimd.com (root through a support SaaS); fluidstack.io; everymarket.com (root via a Ruby job-queue eval injection); and ntc.net.np, highspeed.com.tr, highspeed-sy.com, nextgennp.co, otazujewelry.com, rogarii.com.
  • Pre-deletion projects: artifacts in the exposure show earlier work now absent from the database: the Huffy / Buzz Bicycles estate (detailed in §6.4), and flyertalk.com, internetbrands.com and webmd.com (leaked admin credentials, an internal SSRF channel that bypassed Cloudflare to reach a vBulletin origin, no shell achieved). Recon-level activity also touched stiga.com, carsdirect.com, autos.com, officite.com, apartmentratings.com and atco.co.uk.

6.4 Case study: administrator-level access across the bicycle brands

One pre-deletion target is worth calling out on its own: the Adobe Commerce (Magento) estate shared by Huffy (huffy.com) and its sister brands Buzz Bicycles (buzzbicycles.com) and Batch Bicycles (batchbicycles.com), across the supporting production and staging hosts (www, admin, mcprod, foundation, fleet, mcstaging). All of them were compromised.

The operator held administrator-level access through the estate's own REST API (CMS read/write, backend configuration, customer account data) and because the brands share one platform instance, the access was estate-wide: every brand, every host, staging and production alike. His own notes record every shell-oriented attempt against this well-patched stack as a failure, and none was needed. For this target, administrator access through the API was the compromise.

The pattern is worth remembering: against well-defended targets, the operator fell back to credentials over exploits, and one credential on a shared platform is not one victim; it is all of them. We describe the access here and not the intrusion vector; the relevant technical detail has been delivered to the affected organizations directly.

6.5 What was taken

Across the confirmed intrusions, the operator's collection scripts harvested internal host enumeration, plaintext database credentials, admin API tokens, mail-system configuration, and source code where reachable. We found no evidence of bulk payment-card theft or destructive activity in the artifacts we reviewed, a statement about this evidence set, not a claim about everything the operator may have done elsewhere. Per his own instructions, the objective was access and control. Two findings deserve specific mention: a root reverse shell on a victim's Redis pod, established by a cron job and caught by the operator's listener from the pod's egress address; and a stolen admin token that was still live when we collected it.

7. The operator: profile and tradecraft

The operation is consistently Chinese-language: task hints, script comments, and commit messages are in Simplified Chinese. The operator is technically competent in a narrow sense (he assembled a working multi-agent exploitation platform and adapted third-party tooling) but his tradecraft is shallow: public exploits, default credentials, version-matching rather than original research, and no meaningful operational security.

His working rhythm is visible in the records. Substantial human time went into target selection and hint-writing, with results reviewed by hand; the rest was machine time. Sessions originate from a small set of addresses, principally a Vultr Singapore VPS, an Azure host, and intermittent residential and mobile connections. The most notable is a mobile connection in Kenya on 5 October, whose operator fetched chat.sh, chat_setup.sh, the watchdog scripts, and a raw LLM stream dump from his own exposed directory, apparently checking on the leak while the internet was downloading it.

One further detail: the host's own SSH service was under near-constant brute-force from unrelated parties, with one source alone contributing 15,851 failed passwords. Criminal infrastructure is not private either, as this case shows in both directions.

7.1 Attribution

We assess with high confidence that the command-and-control infrastructure described in §8 belonged to a single operator or a very small group. Our assessment of the operator's identity is more limited:

  • China-linked, Chinese-speaking, financially motivated. The working language, the tooling ecosystem (Chinese-language tooling, documentation and communities around the same framework), and part of the money layer (a Tencent-operated LLM service, farmed for free credits) all trace to China. The economics point to profit, and we found no persuasive evidence of group structure beyond the operator himself. His physical location is unknown to us; the one anomaly in the access records is a residential mobile connection in Kenya on 5 October.
  • No state sponsorship observed in the artifacts. Nothing we recovered matches a nation-state program: no tasking, no shared infrastructure with known state tooling, and every incentive in the operation is financial. We note plainly that the government target set in §6.2 is nationally significant whatever the motive, and that interest from state actors in access of this kind cannot be excluded from the outside. Language indicates origin, not allegiance, and this operator actively suppressed the language signal.
  • Identification routes. The strongest leads are the billing and registration records behind the LLM account pool (six subscriptions, the CodeBuddy identity farm, additional provider accounts) and the operator-side IP addresses. These are provider-side legal processes, not blog material, and they have been referred accordingly.

7.2 Comparison with the publicly reported "SOUL" campaign

In late September 2026, Gambit Security published research, relayed since by The Register and others, on a near-autonomous campaign run by a single Chinese-speaking operator across three public agent harnesses (Hermes, Strix and Cairn), with card skimming, destructive cleanup, and hundreds of victims. Because our deployment shares its exploitation engine (Cairn) and its model assignment (a DeepSeek v4.1 flash-class model) with that campaign, we tested for a link. We compared four things: the harness set and persona configuration, the model access path, post-compromise artifacts (skimming code, destructive behavior), and any overlap in infrastructure, victims or timeline.

QuestionAssessment
Same tooling ecosystemHigh confidence. Same exploitation engine, same model assignment.
Same campaign (shared infrastructure, victims, data)Not supported. No shared indicators found.
Same operatorPossible, unproven. The defining artifacts of the reported campaign (Hermes/Strix harnesses, the persona, skimming code, destructive behavior) are absent from all 16 GB we examined.

Defenders should not merge the two operations when hunting. The tooling overlap is real and useful; the attribution overlap is not established.

8. Indicators of compromise

Infrastructure

  • 202.61.139.15 and 202.61.139[.]137, command-and-control, staging and exfiltration server. Both served the exposed /tmp on port 9000 (SimpleHTTP/0.6 Python/3.12.3), plus ports 22, 443, 8000, 8443 and 4443. Victim exfiltration (PUT /ev/…) observed to .15 ports 8899, 8997, 9099, 9201 and 9955, and to .137:8896. AS152194, CTG Server Ltd, Singapore.
  • Operator-side addresses observed in host logs: 20.78.168.45 (Azure, dashboard access), 20.214.237.197 (Azure), 139.180.159.213 (Vultr Singapore), 102.0.27.92 (Airtel Kenya, mobile), 42.78.192.163 (Chunghwa Telecom, mobile), 8.212.152.211 (Alibaba Cloud Singapore), 43.106.27.167 and 111.223.247.165 (Tencent Cloud), 139.59.247.215 (DigitalOcean Bengaluru), 85.211.254.149, 138.199.21.243.
  • TLS certificate (self-signed, presented by TLS listeners on .15 ports 443/8443/4443 and on .137:443, valid 3 to 5 October 2026 only): CN=202.61.139.15, serial 0CE6C93BC4B91DE00956D73B1D3DF1211B2409D3, SHA256 93:17:8D:D2:F9:25:16:EB:D5:24:81:DE:C2:EE:54:68:BF:5E:97:86:83:9E:67:19:CA:E0:69:EC:D8:C5:41:FF.
  • Operator SSH public key (key comment us@us-VMware-Virtual-Platform): ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKo+sIL3HUlVhjn6PDSGak+C/hEMAx+xL63z8ZhE9tHa.

Behavior

  • Exfiltration: HTTP PUT /ev/<urlencoded command> to operator listeners; staged tooling via GET from port 9000.
  • Listener ports observed: 4445, 4446, 8896, 8899, 8997, 9099, 9201, 9955.
  • Client user-agents: pi (win32 10.0.19045, x64), pi (linux 7.0.0-28-generic, x64), client string ccswitch, Cairn/1.0.
  • Model identifiers in provider traffic: global:deepseek-v4.1-flash, cline-pass/deepseek-v4.1-flash, deepseek/deepseek-v4.1-flash.