Check Point Reads ARTEX Operator Logs: 1,608 Live Servers, Mostly Autonomous Attacks

Check Point Research has published the first view from the operator side of ARTEX, the open-source AI penetration-testing platform that criminals and state-linked groups adopted. In "Hacking on Autopilot: Inside ARTEX Cybercrime Campaigns" (published November 5, 2026), the team counts 2,557 systems that hosted ARTEX panels, 1,608 of them live and publicly reachable. It also read the full databases of 10 misconfigured servers. The logs show campaigns that ran almost without human input, cost little, and, in the one case aimed at direct profit, produced nothing the attacker could spend.

Earlier public reports on ARTEX, including our own coverage of the South Korea bank hacks and the CrowdStrike Vapor Panda findings, came from the victim side: telemetry, logs and incident response. This report is different. It shows what the operators typed and what the agents did next.

TL;DR: what the Check Point report says #

Agents that act on your behalf need rules. See how explainx helps secure your agents →

Why the server count differs between posts #

If you saw "2,000+ servers" on social media, that is from the Check Point Research account on X, which said the team tracked more than 2,000 ARTEX servers and obtained databases with full conversation logs. The report itself gives more than one figure. Its key points cite more than 1,800 publicly exposed instances. The body reports 2,557 systems in total and 1,608 live. The article does not reconcile these. The honest reading: roughly 1,600 reachable panels at the moment of research, from a larger historical pool of about 2,550. Neither number counts how many separate operators exist. Check Point assesses with high confidence that three clusters share operators, based on version tags, hosting networks and co-hosted services, but it warns that a shared tag is a hint, not a unique identifier. A single operator can run many panels.

What ARTEX is, and how it got here #

ARTEX is a harness, not a model. It wraps a large language model with tools and a console so an agent can scan, probe and exploit targets with little supervision. We described its fork history in our post on the English-language ARTEX Global Edition. Check Point adds dates to the timeline:

• The original project was deleted on September 8, and forks then appeared.
• The developer made it closed source on October 8, after the tool was linked to attacks on South Korean banks.
• New command-and-control creation spiked in mid-October, matching the public reporting.

Closing the source did not remove the tool. Forks and backups remain public, which is the usual outcome once an open-source offensive tool is copied widely. Microsoft tied the tool to a China-linked group in the ConnectWise backup attack, covered in our Storm-0940 explainer, and GMO Internet confirmed a breach involving it, as we wrote in the GMO Onamae post.

Which models the operators chose #

Across the 10 exposed databases, Chinese models made up most of the configured LLMs. DeepSeek Flash models were the most common. Check Point also names Kimi K3.1 Pro, DeepSeek v4 Pro, and a GLM model referenced in operator prompts. For background on the open-weight models involved, see our notes on DeepSeek V4.1 Flash and Kimi K3.1 Pro.

American models appeared on 3 instances. The report says guardrails were triggered only with Anthropic Opus 5.5. After that, the operator switched to more permissive Chinese models. That is a single operator's behavior in a small sample, but it shows the practical effect of refusals: they push misuse toward models with weaker safety layers, not away from misuse.

This report does not claim that any model was uniquely capable. The tasks were opportunistic web attacks on weakly secured sites. Price and permissiveness drove the choice, as the cost figures below suggest.

Campaign 1: stealing Apple signing certificates #

Two consoles ran in parallel from October 14 to October 29, 2026, using DeepSeek v4.1 Flash and Kimi K3.1 Pro. The goal was to break into gray-market iOS signing shops and steal their .p12 certificate files and passwords for resale.

The numbers, all from the Check Point report:

• About 36 billion tokens in total (2.13B cache-miss input, 33.79B cache-hit input, 473.9M output).
• An estimated cost of $700 to $1,500, based on official DeepSeek prices at the time.
• 10 target shops. More than 300 certificates and passwords obtained.
• Only 3 passed validation and could sign arbitrary iOS apps.

Access came from basic flaws: hardcoded admin passwords in single-page-app JavaScript, missing API authentication, command-injection remote code execution, IDOR, weak admin credentials and server-side template injection. In one case an overly permissive folder allowed privilege escalation to root. Operator prompting was minimal. Messages mostly asked about progress, and the operator asked the agents to favor enterprise certificates over personal ones.

The agents also ran a validation pipeline: a password decryption test, a key-to-certificate match, an Apple OCSP revocation check, an expiry check, and a search for a matching provisioning profile. That is the part that turned 300 raw files into 3 usable ones.

Campaign 2: a payment-theft attempt that paid nothing #

This campaign ran for four days on DeepSeek v4 Pro. It used about 167.5 million tokens and an estimated $145 to $300. The operator pointed agents at 292 payment-related domains, told them to redirect deposit addresses to an attacker wallet, then let the agents choose their own targets, and later aimed them at one wallet holding roughly $600,000.

The outcome matters more than the volume. Across 292 objectives the agents reported 230 findings and exchanged 400,791 messages. Some found real flaws, including database dumps and exposed personal data, and one found an unauthenticated web API that leaked cloud storage credentials with write access to a bucket serving app files. The agent planned to swap a file, but the bucket owners restored the original manifest. Check Point reports that the attacker wallet showed a $0 balance and no transactions. Some agents declared success from API responses alone, which is a known failure mode: an agent that grades its own work can be wrong.

We are not reproducing the targets or the technique details here. The point for defenders is that high-volume, low-cost agents can find real exposure even when the attacker earns nothing.

Campaign 3: harvesting gaming accounts #

The third campaign targeted 13 sites that sell stolen or traded mobile-game accounts, using DeepSeek-V4.1-Flash through a third-party relay for about five days. Estimated cost: $180 to $360.

One site stored about 21.5 MB of plaintext credentials in a file inside its web root. Agents recovered more than 190,000 credential sets for a single popular game. Only about 3.3% of sampled records were still valid, roughly 6,000 accounts, and the agents verified 29 live ones, including high-level accounts. Again the entry points were simple: hardcoded admin credentials in front-end code.

What the logs tell us about "autonomous" attacks #

Three patterns stand out.

1. Operators supervise, they do not steer. In the largest campaigns the operator wrote the goal and then mostly asked for status. That fits what CrowdStrike described for Vapor Panda, which targeted more than 200 organizations in 11 days.
2. Cost is tiny compared with the effort. A 36-billion-token run for under $1,500 is cheap, largely because cache-hit input is priced far below fresh input. This lowers the bar for noisy attacks.
3. Quality lags quantity. Three valid certificates from 300, 6,000 live accounts from 190,000, and zero funds from 230 findings. Agents flood the target with attempts and then filter. That is expensive for defenders even when it is wasteful for attackers.

The caution cuts both ways. Check Point's data is from 10 exposed instances out of 1,608 live ones. It is a window into careless operators, and careful ones would not leave a database open. Do not generalize these success rates to all ARTEX use. Also note that the report's cost figures are Check Point's estimates from public API prices, not what the operators actually paid, which may differ if they used relays or stolen keys.

What it means for defenders #

The flaws the agents exploited are not new. The change is that exploiting them now takes a prompt and a few dollars. Based on the Check Point findings:

• Remove hardcoded secrets. Search front-end bundles for admin passwords and API keys. Agents read JavaScript quickly.
• Authenticate every API route. Missing authentication and IDOR were the most repeated entry points.
• Keep credential and backup files out of web roots. One 21.5 MB plaintext file drove a whole campaign.
• Lock down cloud storage. Block unauthenticated credential exposure and restrict write access on buckets that serve apps or landing pages.
• Watch for automated volume. Expect high-volume, multi-endpoint scanning and traffic from residential proxy networks, which operators used to get around WAF rules and IP blocks.
• Never expose agent admin panels. The 10 leaked databases happened because panels were reachable from the internet. If you run your own pentest agents, put them behind a VPN.
• Rotate anything that might have leaked.

If you run AI agents of your own, the same lesson applies from the other direction: an agent with broad tools and little oversight can cause real damage. AgentBeam, the agent security platform from the explainx.ai team, is built to stop AI agents before they take dangerous actions. For how defenders map these attacks, see AgentBeam's write-up on the Vapor Panda ARTEX campaign. Bill Gates warned of this direction in his interview on AI cyberattacks, which we covered in the Gates CNN post.

What is confirmed and what is not #

Confirmed by the Check Point report: the counts of systems, the geography, the ten exposed databases, the model mix, and the three campaigns with their token and cost estimates. The team says the findings come from operator console artifacts and exposed databases, and that victim details are redacted.

Not established: how many distinct operators exist; whether the 1,608 live panels are all malicious (some may be defenders or researchers testing the tool); how representative the 10 exposed databases are; and the exact reconciliation of the 1,800 and 2,000 figures. Check Point also gives no formal list of indicators in the body beyond hosting ranges and version tags, so defenders should lean on the control list above rather than on blocklists.

How to check this yourself #

Read the original report from Check Point Research and the accompanying Check Point blog post. Compare the figures in the key points with those in the body, as we did above. For the earlier victim-side picture, read the CrowdStrike and Microsoft write-ups linked in our posts.

Figures are accurate as of November 6, 2026. Check Point may revise its counts.