al-ice.ai

The Attack Tool Got Owned: A Backdoored ARTEX Image Handed Every Installer a Root Shell

Agent & Supply Chain Security by al-ice.ai Editorial

On 4 November 2026, independent researcher BadByte published the supply-chain story the AI-attack-tool boom was owed: a trojanized ARTEX Docker image that hands anyone who can reach the login page an unauthenticated root shell — pulled more than 9,000 times, served by 62 internet-facing consoles, and still referenced by 637 GitHub repositories. A day later, Ostorlab published a remediation companion confirming the mechanics, and The Hacker News paired the backdoor with a second development: CERT-In has flagged an AI-assisted threat actor it tracks as Crafty Falcon actively targeting banks, financial firms, and cryptocurrency exchanges, with ARTEX named among the autonomous attack tools in the assault. The people who went looking for a tool to break into other networks got one that opened theirs.

The swap: eight hours from takedown to trojan

The timeline is the attack. At 10:50 UTC on 8 October 2026, the ARTEX author posted a notice on GitHub: the tool had been abused — including in the South Korean bank intrusions CrowdStrike traced to late September and early October — and it would go closed source with no further releases. The repository came down. That same evening, at 18:50 UTC, a new Docker Hub account named tomicdd was created; at 19:41 it pushed an ARTEX image. Less than an hour later, a GitHub account named trhhubsd uploaded a copy of the source with no fork link to the deleted original. The entire malicious diff was one line — commit a4f4d38, changing the compose file to pull tomicdd/artex. The README was rewritten to call the copy the maintained successor, the prebuilt-binary section was removed, and Docker — meaning the trojanized image — became the recommended install. Until 18 October, the README still told readers the compose file pulled the official image, papering over the switch.

Then came the social proof. GH Archive records 2,449 star events on trhhubsd/ARTEX, 1,098 of them on 12 and 13 October; the repository now shows 1,321, meaning roughly 1,100 stars vanished — most likely fake-star accounts cleaned by GitHub — while the clean continuation RuoJi6/ARTEX lost under one percent of its stars over the same window. At its peak the copycat showed 1.3k stars and 638 forks, outranking the legitimate continuation. On 23 October a user opened issue number 3 — suspect a backdoor — and the repository owner closed it the next day. The account now returns 404, but deletion did not stop the spread: when trhhubsd/ARTEX disappeared, imxv/ARTEXX plus 633 forks inherited the fork network, and 630 of those forks still pull the backdoored image on the same compose line.

What was inside: one function, before the password check

BadByte’s binary analysis is precise enough to quote closely. Built without a trimmed path, the binary at /app/artex admits its own tampering: it was compiled from commit 5c0dbd4 plus uncommitted changes, one commit past where the copycat’s public history stops — so no public source contains the backdoor, and a code review of the repository finds nothing. Against the official v0.3.15 build, 31,054 functions match. Three things differ: a new 160-byte function, server.verifyCaptcha; the login handler server.(*Server).authLogin growing from 1,600 to 2,112 bytes; and a fourth field added to the login request struct. Everything else — sessions, proxy, model calls, log redaction — is untouched, and no new hosts, URLs, or IP addresses were added.

The mechanism: the new login field carries a command prefixed with a secret marker, and if the marker is present the handler runs it through sh -c as root and returns the output — before the username comparison, password-hash lookup, or bcrypt check ever run. Wrong credentials make no difference; no account is needed; from the network the trigger looks like a failed login. The implant never calls home — it waits for requests — and updating does not remove it: the binary reports a dev version string, so one-click updates are refused, the update check queries a releases endpoint that now returns 404, and the working update path (update.sh) simply re-pulls the same poisoned image. The backdoored build also serves a fixed UI build ID on every page, which means one internet search separates trojanized installs from clean ones — the detection handle defenders should use rather than probing the login endpoint themselves.

Who walked into it: 62 consoles, one 15-host fleet, and 637 pointers

Between 2 and 4 November, 62 consoles served the backdoored build: 58 IP addresses and four Cloudflare-fronted domains, every one of them set up and in use, most on the default port 8787 the compose file publishes on all interfaces. The first was up by 20 October, twelve days after the image push; a Jiangsu host switched from another ARTEX build to the backdoored one on 21 October. At 09:55 UTC on 4 November, 46 were still serving it; four had been rebuilt on other images (two on official releases) and twelve had gone dark. Pull counts tell the demand story: 7,946 pulls by 3 November (7,913 for tomicdd/artex plus 33 for a byte-identical re-push, congdonglinux/artex, whose matching digests and long mirroring history point to an unwitting copy), rising past 9,000 by 5 November. A second image, mianhuatang11/artex, and roughly 34 namespaces publishing some 60,000 combined ARTEX pulls round out an ecosystem where only the two identical images carry the backdoor — but the backdoor lives in the prebuilt image, so anyone who runs it is affected whether or not they ever saw the repository.

Two clusters stand out. Fifteen hosts inside 104.168.63.0/24 (ColoCrossing) share one SSH host key seen nowhere else; the machines ran bulk-mail nodes since mid-September, opened authenticated SOCKS5 proxies on 31 October, and brought the backdoored image up across the cluster in thirteen minutes on 2 November — one owner’s fleet, though BadByte is explicit that whether that owner also wrote the backdoor cannot be said. Seven Hong Kong hosts share provider-template keys and look like ordinary customers. The 62 are a floor: 1,645 ARTEX consoles were live on 4 November, only 110 run an official release, 649 run three unattributed single-provider builds, and another 590 run unversioned builds of the same source the trojan was compiled from — indistinguishable from outside without exploiting the backdoor, which BadByte correctly advises against. Installs behind NAT and VPNs do not appear at all.

What the backdoor’s owner gets is the real blast radius, and it extends past the console. ARTEX stores its secrets in plaintext: the database superuser password and LLM provider keys in the container environment, unencrypted model and search keys in the database, engagement targets and scope tables, credentials harvested from targets, findings and evidence, the full intercepted mitm-proxy traffic store plus its CA private key, the JWT signing key (enough to forge seven-day admin tokens), MCP server definitions with commands and tokens, and notification webhooks and SMTP passwords. A compromised console also holds its targets’ unpatched findings, live credentials, and captured sessions — and whoever holds the backdoor can quietly rewrite agent prompts, skills, tools, or MCP servers so the next engagement does their bidding. Anything written to the data, skills, or database volumes survives a re-pull, and one downstream re-publisher pins followers to the backdoored digest through a daily auto-update job. Ostorlab’s companion is blunt about the status: no CVE, vendor advisory, or CISA KEV entry exists, because ARTEX has no active maintainer — so there is no patch to wait for, only an image to replace and secrets to rotate.

Meanwhile, CERT-In names the machine-speed threat: Crafty Falcon

The week’s second primary-source thread comes from New Delhi. CERT-In has disclosed an active and ongoing AI-assisted campaign by an actor it tracks as Crafty Falcon against banking, financial services, insurance, and cryptocurrency targets, following an October alert covering non-bank lenders, fintech, payment providers, and wallet operators. The tradecraft reads like the defensive complement to everything above: publicly available AI-driven offensive tools — ARTEX, PentAGI, Cairn, and CyberStrikeAI named together — executing full attack chains autonomously at machine speed, generating and refining tailored scripts in rapid succession, adapting payloads to target responses, with supporting infrastructure rotating IPs within hours to days. Initial access runs through internet-facing apps and exposed APIs, stolen long-lived hard-coded tokens, supply-chain compromise of source repositories via forged commits, plaintext credentials in code and configs, and remote services without MFA; the payoff is fund-transfer APIs invoked directly from the victim’s own allow-listed infrastructure, defeating loan-creation, KYC, sanction, beneficiary, balance, and per-transaction controls while funds move to mule accounts — with log deletion and endpoint-tool tampering covering the exit, and cloud and non-production environments abused for pivots and shared secrets.

CERT-In paired the warning with its Artificial Intelligence Security Auditing Guidelines, and the requirements read like a direct answer to the agent era: assurance across governance, security, privacy, fairness, transparency, resilience, and auditability; testing of an agent’s documented identities, authorized objectives, approved tool use, permission boundaries, and least-privilege adherence; human approval for consequential actions; and, for high-risk systems, emergency interruption, credential revocation, and controls against automatic restart. Test the tools before they test you — and note the through-line of this entire week: VAPOR PANDA ran ARTEX against 200 organizations in 11 days, Storm-0940 drove it through ConnectWise, CrowdStrike read one operator’s session logs, and now the tool’s own aftermarket is booby-trapped. The defenders’ checklist for this incident writes itself: check the image line in every compose file (637 repositories still point at the poisoned one), rebuild only from a reviewed source tree, recreate — not just re-pull — the container, preserve volumes for investigation, and rotate every secret the container could read, from model keys to the JWT signing key. Related supply-chain lessons sit in the trojanized AI-coding-tool installer behind the Binance heist, the planted AGENTS.md that drove Codex into installing malware, the 42 booby-trapped AI-hook repositories, and the deprecated MCP servers agents keep installing from training data — plus WorkOS and Trigger.dev for what happens when the agent’s own secrets spill.

Our verification was read-only. We read the full BadByte primary report first-hand in full (4 November 2026; 8 October 10:50 UTC takedown notice, 18:50 tomicdd account creation, 19:41 image push, trhhubsd one-line commit a4f4d38, 12-13 October star spike with 2,449 events and roughly 1,100 removed, RuoJi6 clean continuation, 23 October backdoor-suspicion issue closed next day, 404 account; binary forensics with 5c0dbd4-plus-dirty build string, 31,054 matching functions, 160-byte server.verifyCaptcha, 1,600-to-2,112-byte authLogin growth, captcha-field struct change, no new network indicators; pre-credential-check sh -c execution, no callback, dev-version update refusal with 404 release check and update.sh re-pull; fixed per-page UI build ID as detection handle; 62 consoles across 2-4 November with 58 IPs plus four Cloudflare domains, 8787 default, 20 October first sighting, 21 October Jiangsu switch, 46 still backdoored at 09:55 UTC 4 November with four rebuilt and twelve dark; 7,946 pulls by 3 November rising past 9,000 by 5 November, congdonglinux byte-identical re-push, 637 pointing repositories with imxv fork-network inheritance, ColoCrossing 15-host single-key fleet with 2 November 09:25-09:38 rollout and explicit non-attribution, Luogelang seven-host template cluster; 1,645 total consoles with 110 on official releases, 649 on three unattributed builds, 590 indistinguishable unversioned builds; layer-15 implant location, plaintext secret inventory from PG DSN to JWT key to proxy CA, volume persistence, LazyCat pinned-digest redistribution). We read the full Ostorlab remediation companion first-hand (5 November 2026; affected-conditions checklist, preserve-volumes guidance, rebuild-from-reviewed-source and rotate-everything instruction, no-CVE-or-KEV status, no-built-in-auth-beyond-login-form warning) and the full Hacker News report first-hand (5 November 2026; BadByte email quotes, 26 US / 17 Hong Kong / 7 China split, additional namespace list, CERT-In Crafty Falcon disclosure with ARTEX, PentAGI, Cairn and CyberStrikeAI tooling, machine-speed autonomous chains, hours-to-days IP rotation, allow-listed fund-transfer abuse defeating application controls, log deletion and tool tampering, October NBFC alert lineage, auditing-guidelines framework requirements). The CERT-In advisory page itself (CIAD-2026-0058) was unreachable from our network, so CERT-In claims are carried via the Hacker News report’s direct quotations, declared openly. Secondary coverage (BadByte discovery pointers, Indian press) was carried by URL or attribution only. Deliberately not written: CVE-2026-110186 Langflow coverage (same already-covered IBM disclosure batch as our 1 November post, retold 3 November), the AgentScope CVE-2026-123022/123023/123024 cluster (same-day vuldb-only records, no advisory or fix reference yet), and the Zyxel CVE-2026-107441 switch flaw (no AI nexus). We ran no container, pulled no image, probed no console, contacted no one, and downloaded no payload. Brave Search was used for discovery only.

Sources: