# Operation CAIRN: An Autonomous, LLM-Driven Attack Platform Found in the Wild

> A threat researcher reports finding a live, custom-built attack-orchestration platform — "Cairn" — that lets an LLM run intrusions end-to-end with no human in the loop per session: one Docker/Kali container per victim, a fact-graph that remembers what was tried, 229,828 AI-dispatched attack events across 13 days, and a ShellShock-over-SMTP vector that actually landed. Here is what was reported, what is genuinely new (a model reading its own prior work), the IOCs and CVEs involved, and the defences that matter — treated as a single-source disclosure, not yet corroborated by major vendors.

Source: https://playciso.com/blog/operation-cairn-autonomous-ai-attack-platform · Published: 2026-10-15 · Publisher: PlayCISO (https://playciso.com)

Primary source: https://x.com/TheM3gatr0n

---

_Summary first: a threat researcher (handle [@TheM3gatr0n](https://x.com/TheM3gatr0n)) reports finding a live, custom-built platform — "Cairn" — that lets a large language model run intrusions end-to-end with no human in the loop per session. We treat it as a credible single-source disclosure, not yet independently corroborated. Here is what was reported, what is genuinely new, and what defenders should do about it._ ## What was found It started, as these things often do, with a routine indicator-of-compromise scan. The lead was unglamorous: a virtual private server on a Hong Kong-registered APAC hosting provider, flagged for an unusual port combination. On closer look it carried a two-day-old self-signed TLS certificate, a Python API sitting behind HTTP Basic authentication, and — the detail that opens most of these stories — an open directory. That directory held more than 150 files from an active campaign. Inside was not a script and not a toolkit. It was a platform the operator calls **Cairn**: a full attack-orchestration system built around an LLM. The human gives it a target and a goal. The AI does the rest. ## The architecture The reported design is simple and, uncomfortably, sensible: - A dispatcher reads a SQLite target database — 85+ distinct targets were present. - Each victim gets its own Docker container running Kali Linux, isolating one engagement from another. - An LLM receives three things: the target, a goal (for example "obtain webshell or RCE"), and a fact-graph of everything tried in prior sessions. - The model picks the next step, executes it, observes the result, and writes the outcome back into the graph. There is no human in the loop _per session_. The model reported in use is **DeepSeek v4.1-flash**, reached through a pirated account-rotation service ("ClinePass") that cycles stolen subscriptions to defeat per-session rate limits — two live accounts with roughly $10,000 of combined balance remaining. Two Raspberry Pi devices (`pi-workbuddy` and `pi-cline-deepseek`) served as local workers. ## What actually makes this different Automated attack tooling is decades old. What separates Cairn is **memory**. Every session ends with a structured, Chinese-language summary — what was tried, what was blocked, what is now confirmed — written back into the fact-graph for the next run. Across **90+ sessions against a single target**, the model is reading its own prior work and refusing to repeat dead ends. That is the shift. Not a new exploit, but an attacker that accumulates knowledge across time and never gets bored, distracted or discouraged. Over 13 logged days the platform generated **229,828 AI-dispatched attack events** and **17,768 active exploitation attempts**. ## The CVEs in play Reportedly weaponised, concentrated on e-commerce and edge: - CVE-2024-34102 — "CosmicSting", Magento XXE - CVE-2022-24086 — Magento template-injection RCE - CVE-2026-75650 — "StyleSmuggler", a Magento 0-day at the time of the attacks - CVE-2026-53787 — Amasty Order Attributes, unauthenticated file upload - CVE-2026-44277 — FortiAuthenticator pre-auth - CVE-2014-6271 — ShellShock, and the one that actually landed ## The vector worth studying: ShellShock over SMTP The most instructive part of the report is not the newest 0-day — it is an eleven-year-old bug delivered through a mail handshake. The operator injected a Bash payload into the **RCPT TO** field of a mail server. The target ran **qmail**, which strips the recipient domain after the `@` before passing the local part to the delivery agent. In a ShellShock-vulnerable environment, that local part reached Bash and executed — during an otherwise normal SMTP conversation. Command output came back piped via `curl`, embedded inside routine `250` reply codes, so the exfiltration looked like ordinary mail acknowledgements. The logs reportedly confirm it worked: `EXEC [redacted]:25 2026-09-29T18:11:49 id -> 250 ok hostname -> 250 ok uname -a -> 250 ok` Every response smuggled inside a normal-looking SMTP acknowledgement. The lesson is the same one ShellShock taught in 2014: untrusted input must never reach a shell, and legacy mail stacks are still a soft underbelly. ## A second foothold: GCP, Redis, and a five-minute reverse shell The operator also reportedly compromised a multi-tenant SaaS platform on Google Cloud. A compromised Redis pod carried this in its crontab, firing every five minutes: `*/5 * * * * /bin/sh /data/pwn.sh` The script was a netcat reverse shell calling back to the operator's command-and-control, and it was **still running at the time of discovery**. Worse for the victim's customers, environment variables inside the pod exposed internal service names for roughly **20 named customer tenants** — a blast-radius problem as much as an intrusion one. ## This is maintained software, not a smash-and-grab Cairn ships a memory-management daemon, `cairn_guard.sh`, that monitors the dispatcher process, **defers restarts until no attack session holds an active lease**, and rate-limits restart frequency to avoid loops. A comment in the script explains why it exists: the dispatcher once grew to 12 GB, filled swap, and was killed by the kernel's OOM killer. Someone noticed, debugged it, and fixed it. That is a maintainer's reflex — which tells you this is a tool its author intends to keep using. ## What defenders should take from this Hold the specific numbers loosely until a second source lands. But the cheap, high-value actions do not depend on the details being perfect: - Patch internet-facing e-commerce fast. Magento / Adobe Commerce and its extensions are squarely in the crosshairs; CosmicSting and friends are being chained aggressively. - Retire ShellShock-era software. If a 2014 Bash bug can still land in 2026, you have legacy systems that need to go. - Harden SMTP. Recipient and envelope fields should never be able to reach a shell; patch and sandbox mail delivery agents, and alert on anomalous 250-code traffic patterns. - Watch egress and container/pod crontabs. Unexpected scheduled tasks writing reverse shells are a high-signal detection; so is outbound traffic to unfamiliar C2. - Scope multi-tenant blast radius. Leaked tenant names in pod environment variables turn one breach into twenty. Segment, scope secrets, and assume lateral movement. - Rehearse an adaptive adversary. Tabletop the case where the attacker learns from every failed attempt and comes back smarter next round — because that is now a thing that exists. ## Practise it, don't just read about it An adversary that adapts every round is exactly the kind of threat a slideshow cannot prepare you for. On PlayCISO you can work it hands-on, free, in the browser: - War Room — branching incident simulations where the adversary's next move depends on yours. - Detection Lab — write and tune detection rules for IOCs like anomalous SMTP 250 traffic or unexpected crontab writes. - IR Playbook Lab — codify containment for a fast-moving, memory-driven intrusion. - How to write a detection rule and how to triage a SOC alert — step-by-step, ending in the matching lab. _Source: field report by [@TheM3gatr0n](https://x.com/TheM3gatr0n), treated here as a single-source disclosure. We will update this post if the findings are independently corroborated._