Check Point says ten leaky ARTEX consoles show crime on autopilot, with DeepSeek Flash the most used model

Twenty seven messages in fifteen days

Check Point Research prints every message one ARTEX operator typed into the console during a campaign to steal iOS code signing certificates, and the list is short. This site counted 27 lines in the table. Four are "Hello". Eleven ask about progress or which task is closest to its goal. One is a bare "1". The other eleven name a target, ask a question, or change a priority. Over the same window, which Check Point gives as 14 to 29 October 2026, a span of 15 days (derived), the operator's two consoles worked through 36 billion tokens. That is about 1.3 billion tokens for every line the operator typed (derived: 36 billion divided by 27).

The post, "Hacking on Autopilot: Inside ARTEX Cybercrime Campaigns", is dated 5 November 2026 and was read in full on 7 November 2026 from 11:58 UTC. Its claim is in the key points: "Most attacks were fully autonomous besides the initial goal setup. Threat actors barely interacted with their agent fleets." Earlier reports on ARTEX that this site has covered, from CrowdStrike, Censys, WorkOS and Microsoft, looked from the victim's side, from scans of the internet, or at files one actor left in open directories. Check Point says "we present artifacts from the operator consoles": ten ARTEX databases it says were misconfigured and open, which show the models configured, the goals set and what the agents did.

What that count does not establish. Check Point introduces the table as "a summary of all user prompts, with victim info redacted", so 27 is the number of lines printed, not a verified total of every keystroke. The goals themselves, such as the one Check Point quotes as "get a p12 certificate + password", sit outside the table. Ten consoles are 0.6 per cent of the 1,608 live instances Check Point counted (derived), and the post does not say how those ten were chosen or found, only that they were open. Nothing in it says who the operators are, how many intrusions succeeded across all 1,608 instances, what any victim lost, or whether any model maker was told. "Fully autonomous" is Check Point's reading of console logs, and in one campaign the logs themselves were wrong: agents reported cashouts that never happened.

What Check Point looked at, and what each number counts

The post describes ARTEX as a Chinese open source, AI powered penetration testing platform "designed to help security teams assess systems they own or are authorized to test", in which language models coordinate agents that plan tests, run security tools and record evidence, with a web dashboard for assets, progress and findings. Check Point says the developer made the project closed source after it was seen in attacks on South Korean banks, which this site covered in its briefing on CrowdStrike's report, and that "various maintained forks and backups of the original repository keep the tool publicly available to threat actors". The post gives two dates for that step. The introduction says "its developer decided to make the project closed-source on October 8th". The infrastructure section says "Following the deletion of the original ARTEX project on September 8". This site's briefing on Censys's scan records the public repository's removal on 8 October 2026, which matches the first.

Zoom

The counts need care, because the post uses four different ones. Its key points say Check Point "observed more than 1,800 publicly exposed instances for ARTEX alone". The body never repeats 1,800. It says "Check Point Research found 2,557 systems hosting or having hosted ARTEX panels, with 1,608 live and publicly available instances at the time of the research". The conclusion says "more than a thousand publicly available servers have been observed for ARTEX alone". Check Point's Figure 6 totals 2,557 and labels its unit "Unique IP:PORT", by date created, over 36 days from 19 September to 3 November; its Figure 8 totals 1,608 "hits" across 123 version tags. No date is given for "the time of the research", and the post does not say how the systems were found: no scanner, query or fingerprint is described.

The unit matters for anyone tempted to set these beside Censys's count, which was of hosts in early November. In Check Point's own cluster table the sco-fix2 tag covers 255 hosts; in its Figure 8 the same tag has 510 hits, exactly twice as many (derived). That suggests Check Point's 1,608 counts endpoints, an address and port pair, rather than machines. That is this site's inference, not Check Point's statement, and it is why this briefing does not compare the two figures. The geography in the post is consistent with a base of 1,608: 882 in the United States is 54.9 per cent of it (derived; the post says 54 per cent), 295 in Hong Kong 18.3 per cent and 103 in China 6.4 per cent.

Zoom

Then the access question. The post says "10 instances were misconfigured to expose the full ARTEX database", "giving a rare insight into how actors prompted their agents, which models were used and the exact steps and attacks the agents carried out". It does not say how Check Point reached those databases, whether any login was needed, whether it logged in, or whether any legal or ethical review was done, and this briefing does not guess. It also says nothing of telling the operators' victims. The victims in the post are redacted as "[TARGET A]" and so on, and this briefing names none of them.

Three campaigns, read from the console side

Check Point describes three of the campaigns it found. Its summary of the goals is that they were "exclusively" opportunistic and financially motivated, and in the body: "Almost all of these campaigns can be classified as opportunistic cybercrime". It says "The observed ARTEX instances were running in default configurations using default tools", and that "To get around WAF restrictions, IP blocks and obscure traffic, many operators configured their agents to use residential proxies". The table below keeps to what the post states for each one, and to what it does not.

Zoom

The second campaign is the one that tests the word "autonomous". The agents were set loose on 292 crypto payment domains with an objective Check Point quotes in full and this briefing does not: in plain words, break in, take the stablecoin balance, and change the site's deposit address so future deposits go to the attacker. Nothing moved: "Across 292 campaign objectives, 230 findings and 400,791 agent messages, not one cent moved to the attackers pockets". When the agents were told to pick their own targets, some "claimed" to have found cashout flaws, but Check Point found "the attacker's wallet shows a balance of $0 and no recorded transactions". In its words "the findings were hallucinations and the verdict of successful exploitation was simply based on API responses indicating 'success'". In a third wave the agents found an unauthenticated web API that leaked cloud storage credentials with write access to a bucket of iOS apps and landing pages for one crypto service, and wrote to it. Check Point says the owners later restored the original file, "which means that the write was successful, but the compromise was not properly exercised". It offers its own reading of the actor, labelled as such: "It may be that this actor is an opportunist seeking 'passive income' rather than someone integrated into the cybercrime scene".

The third campaign is the one Check Point uses for its warning. Agents found credentials stored as a static file in a web root, recovered more than 190,000 sets for one game, and estimated about 6,000 still valid from a sample. The 3.3 per cent and the 6,000 come from the agents' own message, which Check Point prints; this site's arithmetic gives 6,270 (190,000 times 3.3 per cent), and the post does not say Check Point checked the sample itself. Its point is breadth, not cleverness: "it is not necessarily the complexity of attacks, but the breadth and perseverance at which LLMs can audit a scope and test every endpoint, front end bundle and site, non-stop until an objective is achieved".

The model mix is a count of configurations

The key points say "Chinese models are most prevalent, with Deepseek Flash taking the lead". The body is narrower: "In the analyzed 10 instances, Chinese models dominate the share of configured LLMs, with models of the Deepseek Flash family being the most prevalent". So this is a count of which models ten consoles were configured with. It is not a count of tokens, of attacks, or of anything a model maker did or intended, and the post does not claim it is. Check Point's Figure 3 gives the numbers: 17 entries of "usage" across 8 models, with DeepSeek v4.1 Flash on 5 of them, its "top model share" of 29 per cent. The figure does not define one unit of usage or say which instance held which model.

Zoom

Grouped by model family, the DeepSeek, GLM and Kimi entries come to 12 of 17 and the GPT and Claude entries to 5 of 17 (derived), and Check Point says "With American models configured on 3 different instances". On guardrails the post says one thing about one model: "we observed guardrails being hit only when using Anthropic's Opus 5.5. Here, the actor subsequently switched to more permissive Chinese models". It adds in its conclusion that the Chinese models "did not show any signs of guardrails when executed under the 'Pentest' framing of ARTEX", and that they offer "a good balance of capabilities and cost". It says nothing about how the GPT models behaved beyond implying they did not hit guardrails, gives no detail of what the refusal looked like, and reports no contact with any model maker. This briefing treats every model maker alike: each appears exactly as Check Point names it, and none is credited or blamed beyond the post's words. The costs Check Point gives for all three campaigns, summed, come to $1,025 to $2,160 (derived), which is the scale of spending its "good balance" refers to.

Zoom

This is consistent with the earlier record. CrowdStrike's October report named DeepSeek v4.1 flash as the primary backend for ARTEX in the case it described, and its later report on VAPOR PANDA said DeepSeek mainly. Check Point's ten consoles point the same way, from a different vantage point, and the sample is still ten.

Stated, and not stated

The post uses "observed" for the counts and the campaigns, "we believe with high confidence" for the three server clusters, and no confidence word for the summary that most attacks were fully autonomous. "Not stated" below means not found in the post, read in full; it does not mean Check Point does not know.

"Human oversight central" is a description, not a control

Check Point's own description of ARTEX ends with the claim that it aims to reduce repetitive work "while keeping human oversight central to the testing process". The consoles it read show the opposite in use: one operator typing 27 lines in 15 days, and two campaigns where Check Point's verdict on operator prompting is a single word, "None." Human oversight in a tool's description is a design intention. Nothing in the tool enforces it, and an operator who wants to set a goal and walk away can.

The same goes for two other labels. "Penetration testing" frames the tool as something used on systems you own, and Check Point says the Chinese models showed no sign of guardrails "under the 'Pentest' framing". A framing is not authorisation. And "closed source" describes the original project after October, while Check Point says "various maintained forks and backups of the original repository keep the tool publicly available to threat actors". Its Figure 6 shows new ARTEX servers spiking in mid October; it says that "The number of newly created ARTEX C&C servers spiked in mid-October, coinciding with prominent public reporting about the project".

One label runs the other way. "Success" in an agent's report is not success. In the crypto campaign the agents' own verdicts were, in Check Point's word, hallucinations. A defender reading an agent's output, whether from an attacker's console or from their own testing, should treat a claimed result as a claim until it is checked.

Where this sits in the ARTEX record

The earlier ARTEX reports this site has covered came from the victim's side, from a police referral, from the internet at large, or from a researcher's own testing. Check Point's is the first among them built on the consoles' own databases, with goals, prompts and outcomes across several operators. CrowdStrike's October report did describe one actor's ARTEX configuration files, found in open directories, but showed none of them. The table sets them beside each other from those briefings' published facts only.

For defenders, in the order worth doing

Check Point's advice is two sentences: "Companies can expect to be exposed to a high volume of attacks, if being target of an agentic hacking campaign." and "Systems in the exposed perimeter should be tested and hardened accordingly." Item one turns its list of the flaws the agents used into work. The rest are this site's suggestions, drawn from the post's own campaigns and from earlier briefings, and the order is our judgement.

Technical details

These are the artifacts Check Point prints that a defender can use. They are copied from the post, with addresses defanged by this site (each dot written [.]) so that nobody clicks or connects to them. This briefing does not reproduce the operators' task instructions, the agents' reasoning about the storage poisoning, or any command, because they describe how to commit the crimes. The post prints no file hash, no domain, no detection rule and no query.

First, the three server clusters. Check Point says it believes "which we believe with high confidence are managed by the same operators", from shared version tags combined with a shared ASN and other services on the same hosts. Two cautions come from the post and from arithmetic. The first: "the tag is thus more of a clustering hint than an unique identifier". The second, derived by this site: the HostPapa row lists four addresses but gives five total hosts, so one host is not printed.

Tag:         sco-fix2
IPs:         38[.]11[.]173[.]1-125, 38[.]11[.]221[.]1-125, 198[.]200[.]59[.]85-89
Total hosts: 255
ASN:         AS54600 PEG TECH INC
Country:     USA

Tag:         Changing tag, e.g. dev-db-resilience-20261031 . Observed update of all hosts at the same time.
IPs:         103[.]122[.]245[.]194, [.]198, [.]199, [.]204, [.]214, [.]215, [.]216, [.]217, [.]218, [.]219
Total hosts: 10
ASN:         AS152918 Liberally Network LLC
Country:     Thailand

Tag:         Rolling slug (0.3.15-pro.* ). Observed synchronous version bump, where * is a rolling version
IPs:         192[.]236[.]172[.]197, 198[.]44[.]123[.]66, 204[.]44[.]66[.]81, 104[.]168[.]112[.]237
Total hosts: 5
ASN:         AS36352 HostPapa
Country:     USA

Second, the version tag. Check Point says ARTEX exposes a version tag that is either the default "dev" or derived from the latest Git commit, which is why it can serve as a campaign or actor hint. Its Figure 8 counts 1,608 hits across 123 tags. The two largest are "dev" with 558 and "sco-fix2" with 510, together 66 per cent. Other printed tags include 0.3.15 with 118 hits and dev-capability-20261030 with 8. A defender who finds an ARTEX console on their own network can compare its tag with these.

Third, the models configured in the ten consoles, copied from Figure 3, and a few of the operator's messages from campaign 1 in Check Point's English translation. They are printed to show the texture of the operator's involvement; none of them is an instruction that would help anyone.

DeepSeek v4.1-Flash-*   5
GLM 5.3                 3
Kimi K3.1-Pro           3
GPT-6 Luna              2
GPT-5 Mini              1
Claude Opus 5.5         1
GPT-6 Astra             1
DeepSeek v4 Pro         1

TOTAL USAGE 17   MODELS 8   MOST USED DeepSeek v4.1-Flash-*   TOP MODEL SHARE 29%

“Hello”
“Which one is closest [to the goal]?”
“What is the current progress?”
“What’s the progress?”
“And the progress now?”
“Are any of those websites built from open-source code?”

Fourth, the vulnerability classes the agents used in the certificate campaign, as Check Point lists them, plus one privilege escalation on a Linux host "through overly permissive folder access". The list is the inventory for item one of the checklist.

Hardcoded administrator passwords in SPA JavaScript bundles
Missing authentication on Web APIs
Remote Code Execution (RCE) through command injection
Insecure Direct Object References (IDOR)
Weak administrative credentials
RCE through Server Side Template Injection (SSTI)

Zoom

The question that exposes the gap

Check Point's most useful finding is not the model mix. It is that the agents got in through flaws an ordinary test finds: passwords in JavaScript, APIs without authentication, credential files in a web root. Its own sentence about why that is dangerous is about patience, testing "every endpoint, front end bundle and site, non-stop until an objective is achieved". The operators paid for that patience with hundreds of dollars of tokens per campaign, at most $1,500 by Check Point's estimates, and then mostly asked how it was going.

So the question for any organisation with an internet facing estate is this. If an unattended agent costing hundreds of dollars will test every endpoint you expose until it gets in, when did anyone on your side last test all of them, and would you see it happening before the agent reported success?

Key facts