ARTEX: An Agentic Pentesting Framework Turned Espionage Tool

The adversary’s use of the ARTEX agent framework, the wider ARTEX threat picture, the activity recorded in our environment, and the defensive outcomes achieved.

24 October 2026, UTC. From our record.

22:36:27first local login to the file application

22:50:18web shell written through the file manager: zq7f3k2.jsp

22:51:02command requests: blocked by edge firewall rules

each block followed within seconds by a split, trimmed or Base64-encoded re-send

22:51:16?c=echo Y2F0IC9ldGMvaG9zdHM= | base64 -d | sh HTTP 200

decoded: cat /etc/hosts

On 17 October 2026 a China-based intrusion set started using a publicly released, open-source agentic penetration-testing framework called ARTEX against more than 200 organizations in at least 14 countries. ARTEX is not a tool an operator drives by hand. It plans, it writes its own JavaServer Pages web shells, it re-encodes its own commands the moment a web application firewall blocks them, and in one recorded engagement it consumed about 1.4 billion input tokens before anyone noticed it was there.

What follows is the whole case, written from our side of the wire: what the public advisories state, what our own telemetry recorded, where the two agree, where the record is still open, and what was closed and then verified by attempting the action again as the application account.

The interesting part is not that an artificial intelligence framework was used. It is that the framework arrived better documented than the defensive tooling pointed at it, and that it was being improved while it worked.

Section 3 opens the machinery: one turn of the agent loop at a time, the four channels the bots use to hand work to each other, and the minute by minute trace of that loop inside our estate.

Throughout, source reported material and our own recorded material are labelled separately with these marks.

As always, names have been changed, except for our external entity.

1Bottom line

Nine findings, each marked with where it comes from.

The campaign
Source reporting

The actor used the publicly released agentic framework ARTEX, run mainly on DeepSeek models, against more than 200 organizations in at least 14 countries from 17 October 2026. The source advisory confirms post-exploitation activity at nine. It attributes the campaign to that adversary with moderate confidence.

The controller address is in our record, and we had it first
Our record

Advisory CSA-261253, published 27 October, lists 118.128.151.28 as the ARTEX controller. Our case record had already named that address as the actor’s address on 26 October.

Techniques the advisories report are present in our record
Our record

JavaServer Pages web shells, Base64-encoded echo commands, and queries for Enterprise Admins and Domain Admins. The advisories name no victims, and this post does not identify any.

Shell writes were detected as they happened
Our record

On 27 October, five endpoint web shell alerts on cybercrypto-app-dev-02 each fired within one second of a web shell write. A further alert fired on cybercrypto-app-prod-01 on 29 October at 15:05:22.

The exploit chain is closed where it was proven open
Our record

On cybercrypto-app-prod-01, cybercrypto-app-web-01 and cybercrypto-cloud-01, the web-root write and the root escalation are both closed. Each closure was verified by attempting the action as the application account.

The campaign indicators are enforced
Our record

Every advisory address and domain is covered by kill rules, and the advisory hashes are set to prevent.

No sign-in from the controller succeeded
Our record

All four identity events from 118.128.151.28 are failures.

No campaign malware was found on screened endpoints
Our record

The vendor hashes and file names returned no match across the endpoint telemetry planes over 30 days.

ARTEX is used by more than one actor
Source reporting

The source advisory and Microsoft both report this. A commercial edition went on sale on 16 October 2026.

2Threat overview

What the cited sources state. Confidence language is the source’s own.

2.1 ARTEX

• ARTEX is an open-source agentic penetration-testing framework developed in China. It was published on GitHub by the developer “Autumn-27” (Zscaler ThreatLabz; CSA-261253) and first released in July 2026 (Korea JoongAng Daily).
• Zscaler reports that ARTEX shipped a default blocklist restricting the targeting of government entities and universities, and that the blocklist did not extend to financial institutions.
• Autumn-27 converted the project to closed source on 8 October 2026, and Reuters reported the GitHub page had been taken down. Korea JoongAng Daily notes that previously released source and downloaded copies remain usable.
• On 16 October 2026 ThreatBook launched RedAgents, a hosted platform of artificial intelligence penetration-testing agents. Its launch roster includes Artex Pro, an enterprise edition built on the open-source Artex. ThreatBook states the open-source edition was a personal project of the RedAgents product lead (ThreatBook announcement, 20 October 2026).

2.2 The ARTEX campaign

Adversary and attribution. The advisory identifies a China-based targeted intrusion adversary, first observed in February 2021 using the ProxyLogon exploit chain. The source advisory attributes this campaign to that adversary with moderate confidence (CSA-261253). It describes this as the adversary’s first observed artificial-intelligence-driven intrusion, and states the campaign is separate from the ARTEX activity Microsoft tracks as Storm-0940.

Reach against result

One ARTEX controller, 17 to 27 October 2026. Bar length is to scale. Sources: CSA-261253, CSA-261264.

Distinct organizations reached200+

Engagements20+

Post-exploitation confirmed9

Scale. The source advisory recorded one ARTEX controller, 118.128.151.28, targeting entities in at least 14 countries from 17 to 27 October 2026 (CSA-261253). At least 20 engagements reached more than 200 distinct organizations; post-exploitation was confirmed at nine (CSA-261253, CSA-261264). In one intrusion, the planning agents consumed about 1.4 billion input tokens (vendor research blog, 29 October 2026).

Models. Worker agents were configured with ARTEX_LLM_BASE_URL set to https://api.deepseek.com/v1, and all 35,159 recorded tool-call identifiers follow DeepSeek’s format. The source assesses that the workers almost certainly used DeepSeek models, with high confidence. Planner agents used a second, subscription-based service that the source has not identified (CSA-261264).

Operator and endpoint sensor. Operator instructions were written in Chinese, labelled 【人类指令】 (human instruction). They directed the agent to write web shells, use Base64-encoded echo commands, extract domain administrator passwords and enumerate sensor coverage (CSA-261253). Rather than disable the sensor, the operator directed the agent to avoid it and look for hosts without it (CSA-261264).

Targeting

• Foreign ministries in Latin America, Europe, Asia and the Middle East.
• 19 U.S.-based companies in one engagement, in the pharmaceutical, semiconductor, defense, nuclear and financial sectors.
• Telecommunications providers in the U.S., Belgium and the Philippines.
• Think tanks, shipping and critical-minerals entities, and a U.S. newspaper’s advertising platform.

Sources: CSA-261253, CSA-261264.

Tooling

• BLOODALCHEMY, side-loaded by a legitimate GameHook binary renamed svchost.exe, and a second loader acrobat_compat.dll.
• Cobalt Strike, loaded by libcef.dll.
• Stowaway, SoftEther and Chisel.
• At the Greek government entity GR1, WebLogic CVE-2020-14882 and CVE-2020-14883 were used to deploy web shells.

Sources: CSA-261253, CSA-261264.

2.3 Other reported ARTEX activity

Storm-0940 (Microsoft, 21 October 2026)

• Microsoft reports that Storm-0940 used ARTEX from September 2026 against hundreds of organizations.
• On 15 October the group compromised Microsoft 365 environments belonging to ConnectWise Cloud Backup customers, attempting sign-ins to more than 2,250 tenants.
• ARTEX was used to speed up reconnaissance, password spraying and OAuth application abuse.
• Microsoft reports that threat actors in other regions have also used ARTEX.

South Korean financial sector, late September to early October 2026

• The source advisory reported on 7 October that an actor used ARTEX and commercial models against South Korean financial institutions.
• Zscaler reports personal data of about 67,000 individuals exfiltrated. Recorded Future cites public reporting of at least 68,000 people across at least seven institutions.
• Recorded Future tracks the actor as TAG-217 and places its infrastructure testing as early as 17 to 22 August 2026. It notes that the evidence does not establish that an artificial intelligence system acted without a human operator.
• Zscaler reports that the actor used Claude Code sessions to seek advice on selling the stolen data and to locate Korean-language Telegram channels that sell data.

Time from intrusion to detection, as reported by Korean press

Hours. Bar length is to scale.

Shinhan Bank15 h 26 min

Hana Bank41 h 44 min

KB Kookmin Bank67 h 41 min

2.4 Source assessments

3Anatomy of the bot

How the ARTEX loop actually works, and where it touched us.

This section exists because the phrase “artificial intelligence agent” hides the mechanism, and the mechanism is the part you can see, measure and interrupt. ARTEX is not a program that does a thing. It is a loop that writes a new program for nearly every step it takes, calls a hosted model to decide what to write next, and hands the result to a tool. Everything below is either published in the source reporting or visible in our own telemetry, and the two are labelled separately.

3.1 The framework is a product, and it has a release history

ARTEX was published as open source on GitHub by the developer known as Autumn-27. At the time of collection the repository carried 2,062 stars and 534 forks, a hosted demonstration site, and this technology stack: a Go back end, an embedded Next.js front end, PostgreSQL for state, and model configuration by application programming interface key (ANTHROPIC_API_KEY or OPENAI_API_KEY) or through its own user interface.

Its own licence text forbids using it against any website, online service or networked system, authorised or not. It shipped with default interception rules that block targeting of .gov and .edu domains, including their Chinese equivalents, and did not extend that blocklist to financial institutions. The blocklist is a configuration file, not a control, and anyone who downloads the framework can edit it.

Two months from publication to a hosted commercial edition

2026. The gaps between entries are shown in days.

1. 26 JulyARTEX repository created on GitHub, licensed AGPL-3.0
2. 17 to 22 AugustInfrastructure testing attributed to the South Korean financial actor (Recorded Future)22 days after release
3. 7 to 8 OctoberARTEX use against South Korean financial institutions is disclosed publiclyabout seven weeks later
4. 8 to 9 OctoberThe author converts the project to closed source and the repository is taken down
5. 16 OctoberA commercial successor, ARTEX Pro, goes on sale on a hosted multi-agent platform
6. 17 OctoberThe ARTEX controller at 118.128.151.28 begins targeting entities in at least 14 countriesone day after the commercial launch
7. 24 to 30 OctoberActivity recorded in our estate (section 4)

The lesson for defenders sits in the middle of that timeline: pulling a repository does not recall the copies. Forks are already in the wild, a commercial edition needs no download at all, and one vendor reports detectable user agents on hundreds of internet-exposed instances of the framework. Blocking the tool was never available as a strategy. Blocking the endpoint it thinks with, and detecting the shape of the loop, is.

3.2 The cast: an operator, a planner and workers

Three parties sit in the loop, and the source reporting separates them cleanly.

The split between those last two tiers is the architectural detail worth keeping. Reasoning ran on a subscription model. Execution ran on a metered application programming interface. That is a cost decision, and it produces two different traffic profiles to hunt: a small volume of high value planning, and a large volume of cheap execution. It also means the adversary is on a budget. When the planner profiles ran dry on 25 October, the loop lost its reasoning tier and the workers were left holding context.

The loop, end to end

Three places the loop lives: the adversary’s infrastructure, the model providers it rents reasoning from, and the target estate where its tool calls land. Steps 1 to 4 are from the source reporting; steps 5 and 6 are what we recorded.

3.3 One turn of the loop

Every step the framework takes has the same shape. Read it as a sequence, because each numbered item is something that can be instrumented.

1. An instruction enters. The operator types a goal into the task console. Goals recorded in the source reporting: write web shells, use Base64-encoded echo commands, extract domain administrator passwords, enumerate endpoint sensor coverage.
2. The planner decomposes it. The planner model turns one goal into an ordered list of tasks and writes that list to disk. The published paths show a task store rather than a message bus: /opt/artex/data/tasks/10/deploy2/ is task number 10, second deployment, and /srv/artex-old/ is a previous generation kept beside it.
3. A worker picks up a task and is handed a tool set. The tool set is the framework’s own capability surface: command execution, file transfer, web shell deployment, web application probing, credential reads.
4. The worker emits a tool call. Every call carries an identifier. In our telemetry a climbing number is visible on disk: staging names are i followed by five or six digits, under /tmp or the application account’s home directory. We recorded i25344 through i26145 on 25 October, and i45844 through i46077 on 29 October, an increase of about 20,700 in four days. We read that number as a per-call counter; the framework’s source would confirm it.
5. The tool runs and the output returns into the worker’s context. The model reads the result and decides the next call. That is the entire engine, and it explains why the loop changes technique when a technique fails. The failure is just another observation in the context window.
6. The result is written back to the task record. The planner reads it and issues the next task, or the operator writes a new instruction. The loop continues until the goal is met or the budget runs out.

3.4 How the bots communicate

The framework has four communication channels. Only one of them resembles a conversation, and it is not the one that carries the work.

So the bots do not talk to each other the way a person would recognise. They hand work to each other through persisted state, and the model endpoint is the one participant that belongs neither to the adversary nor to the target. Three consequences follow, and they are the reason this section is here:

• The task store is the coordination point. Interrupt it and the planner has nothing to hand off to.
• The model endpoint is the only hard dependency. Cut it and the worker holds cached context and nothing else. It does not have a fallback, because the framework was never designed to run without a model.
• Volume is measurable. A tool call counter and a token count turn “the agent was active” into a number with a rate attached, which is a far more durable detection primitive than a file hash that dies on the next turn.

3.5 The loop inside our telemetry, minute by minute

The clearest window we have is the evening of 24 October, against cybercrypto-grants-gateway and then cybercrypto-app-dev-01. Times are UTC. Hollow red markers are requests the edge refused; filled markers are requests the application served.

1. 18:58 to 19:57WebLogic console and wls-wsat paths requested on cybercrypto-grants-gateway, every one answered 403Probing before the successful path. Failed attempts are kept in context and do not stop the run.
2. 22:36:27First local login to the file applicationAccess acquired.
3. 22:50:18Write through the file application’s file managerWeb shell deployed, 13 minutes 51 seconds after the login. The first command request reached it 44 seconds later, at 22:51:02.
4. 22:51:02 to 22:57:19Command requests blocked by edge rules, then served as split, trimmed and Base64-encoded variants, HTTP 200 at the application. Shells zq7f3k2.jsp and z8k4m2x9.jsp.The re-encode step. A block is an observation. The next turn works around it, repeatedly, without losing the goal.
5. 22:51:16One served request: ?c=echo Y2F0IC9ldGMvaG9zdHM= | base64 -d | shDecoded, the command is cat /etc/hosts. Reconnaissance through the shell it just built.

# What the served request did, step by step
$ echo Y2F0IC9ldGMvaG9zdHM= | base64 -d
cat /etc/hosts
# ...and the trailing "| sh" then runs that text as a command.

The interval is the interesting measurement. Between the first blocked request and a working replacement form the gap is seconds, and it repeats across several variants in the same window. A person rewriting a blocked command by hand takes minutes and stops after one or two attempts. A loop takes seconds and does not get bored. That difference in tempo is the cheapest machine behaviour signal available to a defender, and it depends on no adversary address at all.

3.6 The loop adapts, so detection must not be anchored

Tool switching inside one primitive class. The privilege step is an interpreter loader hijack. The recorded form is RUBYOPT pointed at a staged file and passed to ohai. The same class covers PERL5OPT, PYTHONPATH, LD_PRELOAD and BASH_ENV. An agent that reads its own error messages will try each of them in turn.

# Recorded: loader hijack through a sudo grant (staged file name abbreviated)
sudo -n RUBYOPT=-r<file>.rb /usr/bin/ohai version

# Recorded: rogue local-mode Chef run with a staged cookbook
sudo -n /usr/bin/chef-client -z -o recipe[probe]

# The class to hunt: any interpreter loader variable carried through sudo
# (regular expression over the process command line)
sudo\s+(-\S+\s+)*(RUBYOPT|PERL5OPT|PYTHONPATH|LD_PRELOAD|BASH_ENV)=

A second, independent execution path. Beside the loader hijack, the same behaviour appeared inside a rogue local-mode Chef run, with the same injection carried in the cookbook. That path is the only one that surfaced two of the six hosts we know about. Had the rule set been anchored to the loader hijack alone, a third of the affected hosts would have stayed invisible.

Which rule saw which host

Recorded event counts per host, 24 to 29 October. A shaded cell is a match. Outlined cells are hosts that only one rule surfaced.

Host	Loader-hijack rule	Chef rule
cybercrypto-app-dev-01	150	528
cybercrypto-app-dev-02	15	21
cybercrypto-app-dev-03	15	2
cybercrypto-app-dev-04	no match	181
cybercrypto-app-dev-05	no match	1
cybercrypto-app-prod-01	42	no match

Sensor inventory instead of sensor evasion. The operator did not instruct the agents to disable the endpoint sensor. It instructed them to find hosts without it, judging by task list and folder listings, and to enumerate sensor coverage. The Chinese term recorded is 猎鹰, a bird-of-prey name the instructions use for the endpoint sensor. The defensive reading matters: endpoint agent tampering is not the adversary’s primary lever, because the cheap answer is to move to a host where there is nothing to tamper with.

A budget, not unlimited capability. Planner profiles exhausted their quota on 25 October, and the planners ran on a different service from the workers. About 1.4 billion input tokens were consumed by the planning agents in one published engagement, while post-exploitation was confirmed at nine of more than 200 organisations approached. High volume, low conversion. The framework scales reach far faster than it scales success, which is exactly why reach is the thing to detect.

3.7 Instrumenting the loop

Map each stage to what is observable and the detection problem becomes a coverage problem. The two highlighted stages are worth more than the rest.

1. Goal entryoperator to plannerNot observable. It happens on infrastructure we do not control.State it as a blind spot rather than pretending otherwise.
2. Reasoningworker to model endpointOutbound HTTPS from a server to a model endpoint, with no browser involved. In the published configuration: api.deepseek.com, and the same hook covers api.anthropic.com, open.bigmodel.cn and api.x.ai.The single highest value hook in this table. The loop cannot reason without it, and it does not depend on any address the adversary rents or rotates.
3. Task storeplanner to workerCreation of task directories and deployment subdirectories on a host: /opt/artex/data/tasks/<id>/<deploy>/, /srv/artex-old/Structural rather than lexical. The directory shape is the framework’s, not the operator’s preference, so it survives a change of target or technique.
4. Loop tempothe tool call counterStaging directory names carrying a climbing number, for example /tmp/i followed by five or six digitsIt counts loop turns rather than content. A rate is comparable across hosts and across days, and it does not care what the tool call did.
5. Privileged executiontool to hostA sudo grant carrying an interpreter loader variable pointed outside trusted pathsIt matches a class of behaviour, so it covers variants the agent has not tried yet.
6. Target interactiontool to applicationFile creation in a served web root; commands in query parameters; encoded or split re-sends seconds after a block; directory queries for privileged groups; ticket requests using a host keytab; credential file readsApplication and identity level, so it holds even when every file hash has changed. A block followed by a working variant seconds later is a machine, not a person.

Reasoning traffic is the dependency the framework cannot replace, and loop tempo is the behaviour it cannot hide. Neither is a hash, and neither expires when the adversary edits a script. Tempo is measurable on any estate the loop touches. Reasoning traffic is measurable wherever an agent runs on infrastructure you can see; when the engine runs on the adversary’s own servers, as it did here, that hook sits with the network egress point and the model provider rather than with the target.

4Activity recorded in our environment

Facts from Incident Response telemetry and the case record. ATT&CK identifiers classify the recorded behaviour; they do not attribute it.

4.1 Contact from advisory infrastructure

The controller address, 118.128.151.28 (ARTEX controller, CSA-261253), as it appears in each telemetry plane:

Perimeter firewall actions on traffic from 118.128.151.28

2,780 rows with an action recorded, 24 to 29 October. Each action is the outcome of the configured policy. Bar length is to scale.

Block (262 destinations)2,530

Allow (26 destinations)156

Trust (16 destinations)94

The remaining advisory infrastructure, as it appears in our telemetry:

4.2 Host activity by tactic

4.3 Identity

No successful sign-in from 118.128.151.28 is recorded in the identity provider sign-in logs.

4.4 Advisory reporting set against our record

5Defensive outcomes

What was closed, how it was verified, and what is now watching.

• ✓Controller identified before vendor reportingThe case record named 118.128.151.28 as the actor’s address on 26 October 2026. CSA-261253, which lists the address as the ARTEX controller, was published on 27 October. 26 OctoberOur case record names the address27 OctoberCSA-261253 lists it as the controller
• ✓Shell writes detected as they happened27 Oct: five endpoint web shell alerts on cybercrypto-app-dev-02, each within one second of a shell write, 16:28:58 to 16:37:26. 29 Oct: an endpoint web shell alert on cybercrypto-app-prod-01 at 15:05:22.
• ✓Exploit chain closed, verified by attemptBoth halves of the chain are closed on cybercrypto-app-prod-01, cybercrypto-app-web-01 (34 roots) and cybercrypto-cloud-01 (7 roots): the application account can no longer write into a served web root, and can no longer run code as root through the sudo loader. Each closure was verified by attempting the action as the application account. A two-minute guard re-applies both closures. cybercrypto-app-dev-01 and cybercrypto-app-dev-03 are contained at the endpoint agent.
• ✓Campaign indicators enforcedCustom indicator groups for Windows, Linux and Mac carry process-kill rules on the advisory addresses and domains. 11 SHA256 values are set to prevent. 11 addresses and 6 domains are set to detect. On cybercrypto-app-prod-01 a host firewall drop set holds the 11 advisory addresses; it had matched 0 packets as of 29 Oct 23:05.
• ✓Web shell detection specific to the applicationA custom indicator group for the file application is enabled. It detects file creation in the file application’s WAR roots, kills the Java process spawning a shell on the file application’s managed servers, and kills sudo environment injection. The application on cybercrypto-app-prod-01 shuts down automatically on any qualifying endpoint alert on that host (60-second check, live from 29 Oct 23:43:41).
• ✓Behavioural detection content measured against live dataOur behavioural detection pack was run against live data. The loader-hijack rule matches four hosts. The Chef rule matches five, two of which (cybercrypto-app-dev-04, cybercrypto-app-dev-05) the loader rule does not surface.
• ✓Application defect fixed at sourceThe file application’s file manager was fixed in the application archive and submitted for test on 29 October 2026 at 22:46 EDT. The result was successful.
• ✓Identity plane heldNo successful sign-in from 118.128.151.28. All four attempts failed (section 4.3).
• ✓No campaign malware on screened endpointsThe vendor hashes and file names returned 0 rows across the endpoint telemetry planes over 30 days.

  Plane	Events screened	Hosts	Matches
  DNS	978,168,281	40,799	0
  File	8,928,426,222	51,309	0
  Process	8,514,413,067	51,338	0
  Connection	8,166,669,337	49,401	0

6Collection coverage and limits

What this record can and cannot show.

7Indicators

Behaviour first, then infrastructure, then hashes. The behavioural rows are the ones that outlive the campaign.

7.1 Behavioural indicators from our record

7.2 Network indicators from our record

7.3 Indicators from the advisories