ARTEX: AI penetration testing, attacks and defences

ARTEX is an open-source framework for connecting a large language model (LLM) to penetration testing tools. An LLM produces and interprets language; a harness supplies the surrounding tools, working context and execution loop. In ARTEX, that loop can turn a testing objective into tasks, carry them out with available tools, examine the results and plan follow-up work.

Think of it as a coordinator with a shared notebook. One piece of work identifies something worth investigating; that observation can remain available when another piece of work begins. Each observation still needs checking before it informs the next decision.

In the source snapshot we inspected, ARTEX has a Go backend, a browser-based Next.js interface and a PostgreSQL database. It keeps records of assets and investigation activity, supports a human operator’s oversight, and connects to a configured model provider.

A planner assigns work, workers can act in parallel using command, file and web tools, and earlier observations can inform later decisions. Its tool selection is configurable. This helps explain how an operator could sustain an investigation across multiple steps.

Actual capability depends on the model, tools, configuration, access already supplied and weaknesses in the target. Forks also differ. Assess the version and configuration involved in each incident when judging its capabilities.

How we assessed it: we inspected source commit e6ec569, dated 7 October 2026, and checked the incident reports below on 14 November 2026. We have not run ARTEX, benchmarked it or independently investigated the reported victims. Software evidence supports our capability description; the named investigators remain the sources for incident findings.

The cases below describe operational use across several investigations. Some reporting overlaps: Google links one cluster to Microsoft’s Storm-0940 reporting. Read each account with its own incident scope and source relationships in view.

South Korean finance: evidence from an attacker’s working files

On 7 October 2026, CrowdStrike reported a campaign targeting South Korean financial organisations, active from late September to early October. Its analysis included ARTEX configuration files and Claude Code session histories found in attacker-controlled open directories. CrowdStrike did not attribute the activity to a named adversary; its assessment of Chinese-language use and financial motivation carried moderate confidence. That does not establish nationality or state sponsorship.

Defensive consequence: preserve the context around suspicious infrastructure and application activity. A tool name, address or language clue needs corroboration before it becomes an attribution judgement.

Supplier access: cloud activity without an interactive user login

In its 21 October report, Microsoft attributed ARTEX-assisted activity to Storm-0940, which it describes as China-state aligned. Microsoft assessed that the actor was responsible for the ConnectWise multi-tenant application compromise and described downstream authentication through applications already granted access. It reported follow-on Microsoft Graph activity, including application credential changes. Microsoft also cautioned that successful authentication did not necessarily establish data access or exfiltration.

Defensive consequence: review the identities and permissions behind supplier integrations. Monitoring only interactive sign-ins leaves an important part of that relationship unexamined.

Incident response: iterative work can leave useful evidence

On 30 October, Google Threat Intelligence Group and Mandiant described ARTEX use in incident response investigations, including post-compromise reconnaissance, lateral movement and privilege escalation. Their observations included rapid sequences of activity, repeated errors and iterative attempts. The report covers several frameworks; its ARTEX-specific findings should not be generalised to every tool or operator.

Defensive consequence: investigate bursts and retries in context. They can provide evidence, but timing or noisiness alone cannot identify AI use.

CERT-EU’s 5 November assessment adds that activity against its constituency highly likely involved ARTEX. The “highly likely” assessment leaves uncertainty about the tool identification, so retain that qualification when using the finding in your own assessment. Its advice includes retaining lower-severity findings in remediation so that small weaknesses do not remain available to be combined.

These reports support treating ARTEX as an operational threat consideration. For Vrax, the useful next step is to connect the reported behaviour to the access and telemetry in your own environment.

One particularly useful defensive lesson comes from ARTEX’s API reconnaissance material. It includes analysis of browser-delivered JavaScript and browser automation to identify routes, API requests and parameters. It can use simulated responses to explore interface components that would otherwise remain hidden behind client-side login or permission checks. The static analysis and browser analysis code support this distinction.

A browser can display an administrative interface using simulated data while the server correctly refuses every protected request. In this case, revealing the interface is not evidence of an authentication bypass: that finding requires evidence of unauthorised access to the real backend.

Assume that a determined investigator may discover the route behind a hidden page or button. The server must independently decide whether the requesting identity may perform that action on that object.

For an organisation with customer portals or multi-tenant APIs, the important question is whether one customer can access another customer’s records. For an application with privileged functions, it is whether an ordinary user can invoke them directly. OWASP distinguishes these object-level and function-level authorisation failures. Both require authorisation checks in the backend.

MITRE ATT&CK gives us a vocabulary for behaviour. Direct probing can fit Active Scanning (T1595); exploitation of an internet-facing service for initial access can fit Exploit Public-Facing Application (T1190). Depending on the observed identity and action, account abuse may fit Valid Accounts (T1078), and adding a cloud application credential may fit Additional Cloud Credentials (T1098.001). Apply a mapping to the specific supporting observation.

The following are proposed investigation hypotheses. They are not tested detection rules or unique fingerprints of ARTEX.

1. Exploration that becomes unusually broad

Look for a source or session moving across many routes, methods or services, especially when that differs from normal use of the application. Requests for browser assets followed by unfamiliar API routes may provide useful context. Repeated access denials or missing routes can strengthen a lead, but a simple count of errors is insufficient.

Telemetry: edge and application request logs with timestamps, request IDs, trusted client-address handling, method, normalised route, status and authenticated identity where available. Compare distinct-route activity and request sequences with the application’s normal patterns.

Tuning: legitimate crawlers, monitoring, quality assurance and approved security testing can produce similar activity. Asset downloads alone are ordinary browsing. Use known testing windows and expected behaviour to inform triage; do not suppress all activity from a familiar address. Correlate a source IP with sessions, identities and other evidence when investigating who or what produced the activity.

2. Attempts to cross an access boundary

Look for repeated denied operations, access to unrelated objects, or privileged actions inconsistent with an identity’s expected role. Where the application records an access decision, correlate the subject, action and object or tenant. A sequence of denials followed by unexpected access deserves investigation; a successful HTTP status alone does not prove that protected data was returned.

Telemetry: application authorisation events and relevant audit records, joined to request and session identifiers. The application needs to record the business meaning of an object-access decision alongside edge telemetry. If that meaning is absent from your logs, record a visibility gap.

Tuning: expired sessions, shared workflows and genuine permission changes can explain some anomalies. Keep credentials, session tokens and sensitive payloads out of routine logs. Use appropriate identifiers and controlled access to the audit trail.

3. Suspicious requests followed by a change on the server

Where exploitation could lead to code execution, correlate suspicious application requests with unexpected child processes, new executable files, abnormal service behaviour or outbound connections from the affected workload. Investigate how the request relates to the workload change. MITRE’s T1190 guidance supports combining application and post-exploitation signals.

Telemetry: request IDs and precise timestamps, workload identity, process ancestry and network destination records where the platform supports them. Containers and managed services may require different sources from conventional endpoint monitoring.

Tuning: legitimate application jobs can launch processes and contact external services. Establish what the workload normally does. Include data-access and application audit events in the investigation, since a compromise can remain within the application.

4. Unexpected application identity activity

For organisations using cloud application integrations, examine service-principal sign-ins alongside changes to application credentials, permissions and roles. In Microsoft Entra, a service principal represents an application’s identity in a tenant. Its activity may occur without a person completing a fresh interactive sign-in.

Telemetry: appropriate sign-in logs and directory audit records, including application/service-principal identifiers, target resource, actor, timestamp, result and correlation identifiers where available. Look for a change that grants or extends access, followed by activity inconsistent with the integration’s purpose.

Tuning: planned certificate rotations, deployments and permission changes can be legitimate. Compare with the owning team’s approved change and expected resources. Review application permissions and credentials alongside user MFA, because these identities have their own access paths. Investigate suspicious access under your incident response process before removing a production integration; preserve evidence and coordinate containment with its owner.

ARTEX’s planning model makes sequence-based investigation a sensible priority. This is our defensive judgement from the source design. Validate the analytics locally against activity from people and other tools as well as the behaviours described here.

Start with an important exposed service and the consequence of losing control of it. A customer-data API and a public information site may need different priorities.

• Reduce unnecessary exposure. Give public services an owner, remove retired endpoints and restrict management interfaces. Check alternate hostnames and direct origin access as well as the main website. Prioritise applicable fixes for exposed components; verify the deployed state.
• Enforce access on the server. Check permissions for the requested action and resource, including tenant boundaries and privileged functions. Include denied-access cases in application tests. Use client-side controls for navigation and backend checks to enforce permission.
• Limit the consequence of a compromised application. Review its service-account permissions, access to secrets, reachable internal services and outbound connectivity. Grant what the workload needs and test restrictions against legitimate dependencies before rollout. Validate these containment measures against the application’s dependencies and the access an attacker could obtain.
• Review application and supplier identities. Give each integration an owner, review its granted permissions and credential lifecycle, and remove access it no longer needs through the approved change process. Include workload identities in investigation and response plans.
• Make the evidence usable. Connect edge, application, identity and workload records. Check clock alignment, retention and the fields analysts need. Tune rate limits and firewall rules to the application’s normal use alongside the server-side authorisation checks.

The harness also contains configurable approval and interception mechanisms. The operator chooses how to configure them. Base your security assessment on the controls you enforce and the behaviour you can observe.

Ask the application owner and detection team to choose one business-critical public application, and include the identity team if it relies on a cloud or supplier integration. In an approved test environment, use synthetic records and accounts with different permissions to check the following:

1. The server refuses unauthorised access. A user cannot access another tenant’s test record or invoke a privileged function. An unauthenticated request is refused where authentication is required.
2. The evidence reaches your monitoring. A small, agreed set of benign requests produces the expected request and authorisation events. Analysts can connect them to the application, identity and access decision.
3. Application identity changes are visible. Where applicable, use a dedicated test integration and an approved credential-rotation exercise to confirm the expected sign-in and audit records arrive. Keep production access and credentials out of the exercise.
4. The response is usable. A controlled log replay or tabletop exercise shows whether analysts can investigate the proposed sequence, distinguish legitimate testing and identify the service owner.

Record what passed, what failed and who owns each gap. This exercise gives the team a recorded result for one control and monitoring path. Use the gaps to choose the next test.

For background on turning this into monitoring work, our guide to defining SIEM use cases explains the difference between an investigation objective and an implemented rule. The metagame article works through the wider threat-informed defence method.

At Vrax, the question we want intelligence to answer is what a defender should do differently because of the evidence. For ARTEX, our proposed answer is to verify the boundary between discovering an application and being allowed to use it, include the identities behind integrations, and check whether monitoring can connect investigation activity to its consequences. Start with one service and retain the test result.

Source review: ARTEX commit e6ec56999175509551a1e43a3ee3b053d0941bd9, dated 7 October 2026. Incident reporting and current reference checks: 14 November 2026. Report dates and activity periods are distinguished in the text. Incident findings are attributed to the named investigators. Proposed defensive hypotheses require local validation.