- Zscaler ThreatLabz recovered an operator's prompt history. It shows AI models working in sequence, with one model reviewing another's findings, and targets in 19 countries and territories named in its prompts.
- The operator sought personal data and phone numbers, and ThreatLabz judges the attacks likely financially motivated. It could not verify which model answered each session.
- Leaders should check their inventory of public-facing systems, scanner-style traffic in logs, and where sensitive personal fields are stored.
The lesson here is about process, not any single AI model. Zscaler ThreatLabz recovered working files from an attack operator who spread the job across several AI models. One model investigated. Another checked the results. Saved notes let the work resume in a later session.
What Zscaler found
In October 2026, ThreatLabz looked into a set of attacks built from three parts: the ARTEX penetration-testing framework, AI coding assistants and the operator's own automation scripts. Early reports named South Korean financial institutions. CrowdStrike reported on related ARTEX infrastructure and that targeting on October 7, 2026. ThreatLabz says the activity reached far beyond South Korea.
The files included a Claude Code prompt history from August 4 to October 4, 2026. They also held AI settings, scripts that sync files between accounts, and tools that route network traffic.
How the workflow runs
ARTEX works as a planner with workers. The operator sets a goal. AI agents split it into tasks, run security tools, and keep records of what they find. ThreatLabz says the operator added tools for web, network and Android analysis.
The tools are mostly familiar open source ones. The report names nmap, which maps open network services. It names sqlmap, which tests for database injection flaws. It names nuclei, which checks for known weaknesses. It also names jadx and apktool, which take apart Android apps. The AI adds the planning.
Memory is the other half. Each investigation got its own folder. The folder tracked targets, discovered pages and entry points, progress notes, vulnerability reports and evidence. A new AI session could read those files and carry on.
Traffic went through a jump server. That is a relay machine between the operator and the targets. Extra proxies gave individual projects separate outbound addresses. Three scripts copied shared instructions across accounts, with backups and checks so they would not overwrite changes. Results were archived to Backblaze B2, a cloud storage service.
One model audits another
The most useful detail is the review step. The prompts show DeepSeek doing the first pass of an investigation. GLM then reviewed that work for gaps. In one translated prompt, the operator told GLM to go back over the work of DeepSeek and its subagents once DeepSeek reported it was out of attack surfaces.
Later prompts also gave GLM investigation tasks of its own. On the jump server, Grok handled research. The operator told a separate AI session to review what Grok found. The prompts describe review in one direction in each case.
This is ordinary quality control. A second reader looks for what the first one missed. The same habit is now visible in how this operator worked.
One caveat matters. The settings name DeepSeek, GLM and Grok. ThreatLabz could not verify which model answered each session. A gateway can serve a different model than the one requested. The report says some sessions may have used Anthropic's Claude models. Treat the model names as requested settings, not confirmed facts.
Who was targeted, and why
The prompts reach well past banks. ThreatLabz says they covered consumer apps, payments, messaging, retail, education, logistics and legal services. The report lists the countries and territories where the prompts asked for scans or investigation. Counting that list gives 19, from Canada and Kenya to Vietnam and the United States. The 19 is a count from the list, not a figure the report states. The report does not say each request led to a successful attack. ThreatLabz reads this spread as opportunistic.
The goals were practical. The operator wanted user records and mobile phone numbers. In one prompt, a database dump without phone number fields was said to have no value. Other prompts asked the AI to decrypt fields, translate database layouts into Chinese and remove extra metadata. ThreatLabz says this points to preparing data for sale. It concludes the attacks were likely financially motivated.
The operator also told the AI not to start direct account withdrawals. ThreatLabz says such transactions could set off alerts.
ThreatLabz says the records point to a Chinese-speaking operator. That view rests on language, time zone and account details.
What leaders should ask
Zscaler is a security vendor. It recommends a Zero Trust approach that limits internet exposure and enforces least-privilege access. The logic holds whatever the product. An automated tester moving from target to target has the most to work with where systems are exposed and poorly inventoried.
Three questions are worth putting to your security team.
First, which public-facing apps and APIs do we know about, and which do we not? The operator's folders began with discovered pages and entry points. Your inventory should be at least as complete.
Second, what do our logs show when one source probes many pages with scanner-style traffic? Tools like sqlmap and nuclei leave patterns.
Third, if a database were dumped, which fields are most sensitive? This operator valued phone numbers and structured personal data. Start protecting those fields.
The operator's edge was a repeatable process, not secret technology. A complete inventory and tighter exposure are the matching answer.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Zscaler ThreatLabz.
