ARTEX and Friends: Enter Agentic Offensive Frameworks

What it is

ARTEX is an open-source, Go-based multi-agent LLM pentesting and C2 platform with an embedded Next.js web console. Google Threat Intelligence Group (GTIG) and Mandiant report threat actors running it in incident response cases since late August 2026. The original author, GitHub user Autumn-27, took the repository down in October 2026 because of abuse. Forks continue, including ScopeWeaver and a commercial version called ARTEX PRO. The report also names PentAGI (VXControl, Kali Linux sandboxes) and CAIRN, and mentions Hexstrike in the introduction.

How it works

Six sub-agents turn a high-level goal into machine commands through frontier or open-weight model APIs. In several cases the operators supplied valid compromised credentials and let the framework run the later stages.

Mandiant's database-to-OS pivot, observed through an application-specific SQL API on an external-facing Linux Weaver OA web server:

SET GLOBAL general_log_file = '<path to webshell>';
SET GLOBAL general_log = 1;
SELECT '<% [webshell content] %>'

The general log is redirected to a web-accessible .jsp file. The SELECT text lands in that file, and the Java servlet compiles the <% %> block, which gives code execution. ARTEX repeated this with incremental file names (cl1217.jsp, f1219a.jsp, z1219.jsp). It rewrote each webshell after errors such as "variable 't is already defined" until one ran cleanly.

Behaviours that separate it from a human operator:

• Execution sequences ran in bursts of about 2 to 25 seconds, with long pauses between phases. One case showed 27 events in 23 seconds of AWS permission probing across security groups.
• After a "script too large" error it trimmed the script and relaunched it, deploying a 17-snapshot instance in about 10 seconds.
• The Weaver OA step produced 240 log events. Errors were possibly caused by sub-agents overwriting one another.
• It created files named artex-probe-* with five-digit, roughly incremental numbers. Similar counters appeared in account names, passwords and email subjects.

UNC7228 (overlaps Microsoft's STORM-0940, PRC-nexus, reported by Wiz) moved from first compromised account to deep access in about four hours, and in one case 15 minutes. It customized tooling per victim and fell back to open proxies when infrastructure was blocked. Targets were in the US and Europe: enterprise software, industrial automation, semiconductors and telecoms.

What to do

Mandiant's five layers:

1. Control plane. Restrict administrative interfaces to trusted networks or jump hosts. For Azure App Service, limit Kudu/SCM access, disable basic publishing authentication where not needed, and consider run-from-package. Alert on admin access from new networks, hosting providers or geographies.
2. Identities and keys. Replace long-lived credentials: AWS IAM roles instead of static keys, Azure Managed Identities, disabling Azure Storage Shared Key auth, Google Workload Identity Federation, GitHub fine-grained PATs or Actions OIDC. Restrict iam:PassRole to specific roles, with conditions such as iam:PassedToService. Scan continuously for secrets.
3. Configuration and attack paths. Segment DMZ workloads from identity and internal systems. Strip database account privileges that allow OS command execution, arbitrary file writes or server-wide settings changes. This directly blocks the general_log technique. Hide stack traces and SQL errors from external users, since the agents use errors as feedback. Harden AD CS (remove ENROLLEE_SUPPLIES_SUBJECT where unneeded, enable Extended Protection for Authentication), and enforce SMB and LDAP signing and channel binding.
4. Application development. Add rate and recipient limits to high-impact APIs such as email and notifications. Inventory remote-execution and deployment capabilities. Run SAST and DAST, and consider agentic code review.
5. Behavioural detection. Baseline identities and workloads. Alert on changes in authentication origin, bursts of control-plane calls, bulk object access, and sequences across telemetry sources. Restrict server egress and watch for webhook, OAST, tunnelling, file-transfer and external AI destinations.

Google SecOps rules named in the post: Suspicious Webhook.Site Interaction, Suspicious Curl Invocation, Cmd Launching Curl, AWS Cloud Accounts Getcalleridentity.

Caveats

• GTIG says current use is early-stage: noisy, forensically loud, trading stealth for speed. It expects stealthier use later, with fully autonomous, more sophisticated attacks in 3 to 6 months.
• Most observed PentAGI activity stopped at WHOIS mapping or vulnerability scanning, though some operations reached intrusion and persistence.
• Static indicators will miss much of the activity because it uses valid credentials and supported functionality.
• GTIG notes that detecting an attack in time does not by itself stop the objective being completed.
• Secret-store detections overlap with legitimate automation. Baseline known-good automation first or expect false positives.
• The post gives no IOCs beyond the file-name patterns above.