Artex AI Attack Framework: 1,465 Exposed Consoles, Hunt Your Ranges

The most useful fact about ARTEX for a defender is not that a language model drives the attack. It is that the people running it keep leaving the operator console on the open internet, mostly on rented servers, where a scanner can find it in minutes. Censys counted 1,465 exposed ARTEX consoles on November 3 and 4, 2026. If you sell or run hosting, the question this week is whether some of those sit in your own address space, and whether the weak spots ARTEX looks for sit on your servers.

ARTEX is an open-source, AI-driven autonomous penetration testing framework published on GitHub on July 26, 2026. Since then it has been tied to data theft at seven South Korean financial institutions and, by Microsoft, to the Storm-0940 campaign behind the ConnectWise Cloud Backup supply-chain compromise. We covered the earlier wave of AI-run intrusions, where an agent swept 460 servers but known CVEs did the breaking. ARTEX follows the same pattern, and its exposed consoles hand defenders something those campaigns did not: a fingerprint.

Why are so many ARTEX consoles exposed on hosting networks?

Most exposed ARTEX consoles sit in a few blocks of rented hosting that share one build. Censys found about 650 of its 1,465 hosts in two blocks of identically configured servers, which leaves roughly 815 distinct-looking deployments. Its researchers read the uniform layout as a provisioning template, not hundreds of separate operators.

The detail is specific. In the Censys write-up, 493 consoles sit on PEG Tech address space (AS54600) across 13 /24 networks with the same port layout, and 157 sit on Yancy Limited space (AS138415), mostly in 156.234.0.0/16, built on a shared CyberPanel and mail-server template. Censys does not say the providers run these consoles, and some instances likely belong to authorized testers. What the clustering suggests, on Censys's reading, is that someone is buying servers in bulk and deploying ARTEX onto them from a template, which is exactly the kind of pattern an abuse desk can find with one query.

The counts from different teams do not match, and that is worth understanding before you quote any of them:

Hunt.io, working from the infrastructure behind the Korean breaches, found about 1,300 consoles by page title, 1,303 hosts by malware classification tag, and only 19 by searching for "ARTEX" as a certificate issuer. The spread is a method artifact, not a contradiction. Censys also saw renamed and localized consoles such as "ARTEX MX", so every number here is a floor.

One correction to the coverage. TechCrunch reported more than 800 deployments reachable without a password. The Censys post we read makes a narrower claim: the console does not need to be public at all, yet these are. It does not describe a login bypass or default credentials. Treat "exposed" as "findable", not "open to anyone".

What ARTEX is, and where it has been used

Per Microsoft, ARTEX is a set of cooperating agents built in Go behind a Next.js web console. It is model-agnostic, and its agents carry an intrusion from first scan to data theft while mapping what they find into a graph. Its author said on October 8 that the project would go closed-source, but forks and mirrors of the public code remain in circulation.

Three dates anchor the timeline. On October 7, CrowdStrike reported an actor using ARTEX against South Korean finance; CrowdStrike's moderate-confidence read is one financially driven operator who speaks Chinese, not an established group. Roughly 66,000 to 67,000 people and about 2,200 corporations were affected, according to the figures Hunt.io and Security Affairs cite. On October 21, Microsoft attributed ARTEX use to Storm-0940, a group it assesses as China-state aligned, and said stolen application credentials were tried against over 2,250 customer tenants. Microsoft counts those as attempts, not confirmed compromises. Then on November 3 and 4, Censys ran its count.

The model wiring is telling. Hunt.io found the Korean operator ran DeepSeek as the main model with GLM and Grok as backups, reached partly through a reseller, and drove it from a Claude Code install routed through a local shim to DeepSeek rather than to Anthropic. Cheap, swappable models behind a familiar coding-agent tool: that is the economics behind this wave.

How do you find an ARTEX console on your own network?

Search your address space for an HTTP page title that starts with "ARTEX" served alongside Next.js static assets, and check port 8787 first. That is the Censys fingerprint. Then look on the same host for open directories, tunnel listeners and LLM proxy software, which tend to appear before the console does.

Hosting providers can run this against their own ranges today. Everyone else can use the published infrastructure to check egress and authentication logs. The block below collects the fingerprint and the indicators the primary sources released; IPs are defanged.

# Console fingerprint (Censys, Nov 3-4 2026)
http.title       starts with "ARTEX" followed by space, ":" or "-"
http.body        references /_next/static/
port             8787 (default), also 8790, 443, 80
renamed titles   "ARTEX MX", "ARTEX v2"
same-host clues  open directories, Vshell or FRP listeners,
                 CLIProxyAPI or New API LLM proxies,
                 mitmproxy banners, short-lived Python SimpleHTTP on high ports
# Korean finance campaign infrastructure (Hunt.io)
38.244.50[.]120          ARTEX console, login on 443 and 8090
23.248.226[.]250         open directory; staged JNDI/LDAP setup on :8001
154.201.79[.]246:443     rotating proxy
130.94.31[.]86:18888     script host
156.251.11[.]39          SMB recon kit, writes artex_probe_11876.txt
# Storm-0940 / ConnectWise activity (Microsoft, Oct 21 2026)
144.172.64[.]99
144.172.64[.]60
144.172.64[.]128
user-agent       Python-urllib/3.12
user-agent       python-requests/2.31.0
user-agent       python-requests/2.34.2
user-agent       curl/7.88.1
user-agent       azure-toolkit/1.0

Two cautions. The open directories Censys saw were often live for only hours to a few days, and between November 3 and 5, ten closed and fifteen new ones appeared. Scan history keeps the file listings after the operator cleans up, so search history, not just the current state. And the user agents are generic on their own; they only mean something when paired with the IPs or with the behavior described next.

The weak spots ARTEX went after were ordinary

None of the published ARTEX intrusions needed a new exploit. Microsoft says Storm-0940 used it to speed up scanning, password spraying and OAuth application abuse. CrowdStrike and Genians described insecure direct object reference (IDOR) testing against Korean loan and inquiry services, meaning the agent changed record IDs in requests to pull other customers' data. Hunt.io confirmed JNDI/LDAP exploitation used for command execution, and recovered kits for DedeCMS, FangCMS and a RuoYi/Spring admin console, though it says not every recovered tool is confirmed as used against the Korean victims. Censys found a sudo privilege-escalation exploit and a Windows lateral-movement kit in the exposed directories.

What changes is tempo, and tempo is detectable. In one Microsoft-observed phase between October 10 and 14, a single address sprayed 327 accounts at eight organizations, logging more than 151,000 failed sign-ins and peaking near 2,900 failures a minute on October 11. Almost 98% of the responses were lockouts. Per-account lockout did its job there, but the useful alert is the aggregate: failures per source per minute across all accounts. In other cases Microsoft measured less than three hours from first targeting to privileged cloud access, which leaves no room for a weekly log review.

For a server operator, the IDOR finding is the one to sit with. An agent enumerating record IDs looks like a burst of near-identical requests that differ only in one numeric parameter, each returning 200. That pattern shows up in ordinary web access logs, if someone is watching for sequential parameter walks rather than for exploit strings. We made a similar point about the agent inside Thailand's finance ministry: these tools are caught by what they do on the host, not by a signature.

Close the admin panels ARTEX scans for

• If you run hosting: run the console fingerprint against your own ranges and route hits to your abuse process. A template-built cluster usually means one customer account holds many of them.

• Remove public access to admin services. Hunt.io's guidance is to put them behind a VPN or an allowlist; the Korean breaches went through internet-facing systems, and its findings point at exposed administrative services and reused credentials.

• Alert on spray rate, not just lockouts. Count failed logins per source across all accounts per minute.

• Watch for outbound LDAP and unexpected DNS callbacks from Java application servers, the signal Hunt.io tied to the JNDI activity.

• If you used ConnectWise Cloud Backup, follow Microsoft's order: preserve sign-in and audit logs before you rotate credentials or delete enterprise applications, and review service principal sign-ins back to October 1.

ARTEX going closed-source will not shrink this. The forks are out, the consoles are templated, and the counts above are a floor. Expect the next report to name a new AI front end on the same rented blocks, aimed at the same unguarded login pages.