Anatomy of ARTEX: Infrastructure, Indicators, and Implications

Abstract

October 2026 saw a surge in threat actor adoption of ARTEX, an open-source, AI-powered penetration testing framework designed to automate offensive security operations. The original project was first published in July 2026 by Autumn-27 on GitHub, but the repo was made private on the 8th October following reports of abuse. However, many forks and clones of it were created in that time, and they remain available in public repos. 

The tool has been linked to various malicious campaigns, including attacks against financial institutions in the Republic of Korea, and is even believed to be the tool used to compromise the Dutch Institute for Vulnerability Disclosure (DIVD) in minutes using two zero-days. You can read our in-depth analysis of the DIVD attack here. 

We have been conducting lab research to analyse the behaviour and functionality of ARTEX, collate the IoCs it leaves behind, and ultimately improve capabilities and readiness for incident responders. 

The English-language fork by BaaRai on GitHub was used for our lab test, as this seems to be the most prevalent copy based on investigations we have been involved in. It is worth noting, for anyone looking to do their own testing, that some reports claim that some versions of ARTEX (and, in particular, pre-made Docker images) contain backdoors. As with any testing, review the content yourself and run instances in isolated sandboxes.

Architecture and execution

ARTEX does not provide its own LLM. It provides task management and orchestration, state tracking, and content window controls to automate workflows using the operator-supplied model(s).

ARTEX is built using a Next.js frontend, Go backend, and PostgreSQL database for persistent storage, with additional data residing in the persisted skills and data directories. It supports extensible tools and skills, allowing actors to develop or integrate third-party plug-ins to expand the capabilities of ARTEX.

tools operate at the core software level and allow it to perform defined actions by adding new functions, API calls, or executables to the platform.

skills provide abstraction for these; they are typically scripts and instructional files which provide ARTEX with the knowledge and direction for using underlying tools effectively.

The underlying engine that powers decision-making in ARTEX follows the same blackboard architecture used by Cairn: Tasks are defined by an Origin and Goal, with an Origin being a target system in its current state, and the goal being what you wish to achieve with it (e.g. shell access, database dump, denial of service).

The planner loop runs alongside agents and workers to iteratively grow a graph comprised of facts and intents, starting at the origin and growing towards the goal. These are explained here, along with hints:

Every iteration of the planner loop links LLM decision-making to the executable tools and skills, and instructs workers to concurrently execute them in different contexts, then delivers updated facts and intents as the output of this run:

This is what allows ARTEX to automate attack-path exploration, including testing and iteration. Strand's attack path simulates the internal graph that was built up by ARTEX during its run, reconstructing each stage of the growth towards the attacker's goal by piecing together links between forensic artefacts.

The fallout from this, as explained in our analysis of the DIVD intrusion, is that the model explores the attack vectors at machine speed, generating a colossal amount of noise in the target environment.

Identifying panels

We can fingerprint ARTEX panels by using the sha256 hash of the default favicon that it is packaged with. Additionally, since ARTEX is ready to be put behind a reverse HTTP proxy out of the box, we have included an indicator for servers which identify their HTTP Basic authentication realm as "ARTEX". Note that favicons can be copied and realms customised; private deployments and modified forks may evade both.

On the 2nd November, Censys identified 1,369 live matches. These are servers that match our fingerprint query, including legitimate deployments of the tool, rather than confirmed malicious servers or unique operators.

The Censys query is provided in Appendix 1 reference.

Investigation artefacts

Working with incident response teams that deployed Strand into compromised environments, across multiple unrelated victims, in September and October 2026, we observed forensic artefacts with recurring naming conventions and behavioural patterns: iteration-numbered artefact names (pentest-i<n>, zzprobe-i<n>, zz<n>), clearly labelled "probe" accounts, throw-away accounts created with disposable mailboxes, dead drops using third-party media sharing sites, and machine-speed tempo.

Resource and identity naming

ARTEX does not make much effort to attempt detection and discovery evasion since its primary purpose is to simulate attacker activity in authorised environments. Additionally, operators using commodity LLMs through commercial APIs (such as those offered by Anthropic and OpenAI) are subject to safeguards which may limit their ability to hide or blend their activity with regular application data.

For this reason, it is common to see short labels built around artex, pentest, probe, and zz recur across created accounts, application objects, and uploaded files - usually with numeric or variable suffixes. The iterative numeric suffixes are typically 3-5 characters in length. ARTEX favours the use of hyphens to segment the labels it generates. This table contains artefacts from our lab testing and anonymised replicas of real-world artefacts.

Numeric components sometimes link execution to collection: we have noted instances where the same number suffix appears in system commands and later in a metadata token used for data exfiltration.

Rising numbers in artex account names suggest iteration, meaning that responders may be able to attribute artefacts following the same naming convention to activity timeline: lower numbers suggesting early-stage reconnaissance, and higher numbers being more common in later-stage data collection and exfiltration.

Across all tests and compromise data shared with Strand, the artex, probe, zz, and PENTEST conventions appeared multiple times.

Throw-away accounts and registration artefacts

Registrations mix obvious probe labels with plausible personal names and disposable mailboxes. Note that, from our testing, it appears ARTEX may attempt to use mailboxes it does not control. For example, in testing against Strand’s own website, our 'contact us' forms were targeted with fake email accounts from maxxspace.com and fldubai.com domains that ARTEX had not created and did not have control over. Additionally, the domain that ARTEX chooses is not consistent across runs.

The abnormal volume of activity, paired with the behaviour, from newly created accounts leaves a conspicuous identity trail: In our lab, created accounts were immediately used to probe storage, redirect, and authorisation functionality with extremely high request traffic volume.

Web requests and application discovery

OpenAPI and JavaScript source-map retrieval commonly precede self-registration and immediate data requests. Exploration then extends through application features: X-User SSO bypass, directory reads, remote-repository proxies, and webhook tests. Recorded activity from our tests left dozens of artefacts across URL testing/fuzzing, including attempts targeting /etc/passwd and ../../tmp overrides. 

Our lab also showed further broad exploration, including HEAD-based wordlist sweeps of edge functions, RPC functions, and approximately 200 database tables. We also noted that ARTEX attempted to use forged JWTs for authentication, although it was not successful in this case.

In one case, ARTEX did use custom User-Agent values which identified the tool's activity - each new request had a value which stated the exact data that the given request was attempting to access.

Endpoint discovery can be re-configured by operator input. In our lab testing, after completing enumeration of the pre-auth attack surface of the target webapp, the tool offered onward work including using wordlists and directory brute-force tools (ffuf/dirsearch):

Uploaded files and payload artefacts

Uploaded files carry the same functional naming. Our lab produced the following through Strand's evidence-upload features:

These uploads show exploration moving from API access into file-rendering surfaces. Successful payload execution has not been established. The files contain functional payloads generated on the fly, meaning that file hashes will be different every time for these potentially malicious files.

Callback destinations and collection artefacts

ARTEX uses third-party services as callback destinations and dead drops, alongside cloud metadata services and storage within the victim's own environment. Activity includes event-subscription tests and collection of infrastructure configuration, CI environment data, and production metadata tokens. It later uses this data to assess privilege escalation options, audit downstream client environments, or support data exfiltration. in one investigation we saw ARTEX attempt to use harvested and generated authentication artefacts to begin auditing multiple downstream customer environments.

ARTEX will also adapt its callback and exfiltration techniques to bypass environment restrictions. We have seen it use wildcarded DNS services which resolve domains to IP addresses embedded within them in order to bypass IP filtering in the target environment.

Execution tempo and impact

The activity is fast and noisy, leaving throw-away identities, failed probes, and short-lived infrastructure. In our lab test, ARTEX progressed from discovery and account registration to rapid application, database, and storage probing¹. Strand identified the following bursts of activity:

• 10:24: 233 anonymous requests in one minute, covering 232 different paths, including table-name guessing, sign-up, recovery, and sign-in attempts.

• 11:18: 439 anonymous GraphQL queries in 46 seconds.

• 11:20: 731 anonymous storage-probing requests in the busiest minute of the test, peaking at up to 55 requests a second.

• 12:18: about 700 requests in 3 minutes, spanning RPC-function enumeration, HEAD-based table checks, and attempted writes and uploads.

• 12:50–13:10: around 1,400 requests during a sustained burst of activity.

• 13:23: 426 requests in 40 seconds using two test accounts to probe application access.

• 13:28: a further database sweep comprising 262 requests.

¹ Testing was conducted against the Strand platform in a controlled, isolated environment; no real-world data has been exposed.

Correlating the artefacts

The recurring combination is functional self-identifying naming, disposable identities, broad application probing, and rapid follow-on actions. Incrementing numbers in generated labels can correlate to attack stage; matching numeric identifiers can connect activity across stages of an attack run.

Strand's agentic analysis is adept at identifying all of these artefacts, both evidential and behavioural, and is capable of building an accurate picture of malicious activity - shown here in the generated attack-path from its investigation into our lab testing:

Reach out to the team at sales@strandintelligence.com to find out how we can reduce the time frame of your investigations. Our platform offers functionality from evidence collection, attack path and data exfiltration analysis, through to persistence hunts and report generation, ensuring all artefacts are considered at every step of the process.

Further Observations: Cost and industry impact

Through the cyber verification programme, we were able to use Mythos 5.1 as the model powering our ARTEX instance. Using the default LLM configuration options in ARTEX (200k token context window), our test lasted for just over 3 hours and used 165,149,064 input tokens and 1,741,924 output tokens, amounting to an overall cost of $1,727.13.

Ultimately, although powerful, ARTEX acts only as an abstraction and orchestration layer for resources that an actor already has access to. LLM safeguards will affect threat actors who are not hosting their own models. Routing traffic through anonymised and proxied infrastructure will also incur additional costs while potentially degrading latency and limiting bandwidth.

In short, ARTEX does reduce the level of technical proficiency required to execute complex attack workflows, making advanced offensive capabilities accessible to less experienced operators. However, it remains just one tool in an arsenal that still requires a large, complex environment of attacker infrastructure built around it. Actors without the knowledge, experience, and resources required to create such an environment and utilise ARTEX to its full potential will only see limited returns.

Experienced, established, and state-sponsored actors will benefit from using this against lower-priority and less security-aware targets, but it is simply too noisy to be used against their high-value targets without making modifications to the tool.

Appendix 1: ARTEX Panel Censys query

host.services.endpoints.http.headers: (
    key = "WWW-Authenticate"
    and value: "realm=\"ARTEX\""
)
or host.services.endpoints.http.favicons.hash_sha256 = "8b567c0244f2dbee787165aea9c4ddabaaafb0fdb3b29899ac898c60a589856b"