ARTEX and Friends: What Google and Mandiant Saw Agentic Attack Frameworks Do

Google and Mandiant say attackers are now running open-source AI pentest frameworks in real intrusions, and that the frameworks compress attack timelines to seconds. In a report dated October 31, 2026, the Google Threat Intelligence Group (GTIG) and Mandiant describe ARTEX, PentAGI and CAIRN used in incident response cases since late August 2026 against government, technology, chemicals, manufacturing and telecommunications targets. This post covers what ARTEX did, what separates it from a human operator, and the five defense layers Mandiant recommends. If you run coding agents, the lesson is about the credentials these tools harvest.

What happened, in plain terms

Pentesting platforms have been abused before. Google notes that Cobalt Strike and Metasploit were built for security professionals and later adopted by espionage and financially motivated actors. The new part is that the platform itself is an LLM-driven team of agents. According to GTIG, ARTEX is an "autonomous, multi-agent LLM-driven pentesting and offensive command-and-control (C2) platform written in Go with an embedded Next.js web console," originally released on GitHub by the user Autumn-27. It splits the attack lifecycle across six sub-agents and uses frontier and open-source model APIs to turn a high-level goal into commands.

Google dates adoption to late August 2026 and says it spans financially motivated extortion groups and suspected China-nexus espionage clusters. The original repository came down in October 2026 after widespread abuse, but forks live on, including the localized ScopeWeaver and the commercial ARTEX PRO.

This is not the first ARTEX story on Beam. CrowdStrike tied it to attacks on South Korean banks and to Vapor Panda's 200-organization campaign, Microsoft linked it to Storm-0940 and the ConnectWise supply-chain compromise, and Wiz described seven fingerprints of agentic attacks. The Google report adds incident response detail across several unrelated victims.

The attack chain, step by step

GTIG maps observed ARTEX activity onto the attack lifecycle. In several cases the intruders gave ARTEX valid credentials and told it to carry out later stages. The steps below follow the report.

1. Reconnaissance with stolen cloud credentials

ARTEX mapped what stolen Azure credentials (SAS tokens, service principals, Kudu credentials, storage account keys) could do using sub-second checks. It wrote and deleted a tiny test blob in roughly 330 to 400 milliseconds and ran an 8-second ARM deployment validation sweep across 11 resource types. On AWS it tested IAM permissions with DryRun flags. Against a web server it made more than 500 requests, probing file names and extensions and reading 200 versus 403 responses.

2. A foothold through legitimate management features

The agent abused Kudu administrative APIs to run commands and stage Python, C# and PowerShell scripts. On an internal Windows database server it used native curl to pull down generated scripts and post results back across 491 rotating webhook.site URLs.

In one case it reached an external-facing web server with supplied credentials and used exposed SQL API calls. It ran SET GLOBAL general_log_file pointed at a web-accessible path, then SET GLOBAL general_log = 1, and issued SELECT statements containing JSP code so that the MySQL log became a webshell. Google saw multiple iterations with names such as cl1217.jsp, f1219a.jsp and z1219.jsp, each corrected after the last one failed to run. That process produced 240 log events, with errors that may have come from sub-agents overwriting one another.

3. Privilege escalation inside Active Directory

ARTEX ran Kerberoasting scripts to request service tickets for crackable service accounts, used SQL injection to dump database credentials, and, after an offline cracking pause, ran DCSync scripts to take the domain krbtgt key, cloud AD-sync credentials and domain controller machine hashes. It also created accounts with is_admin=true within minutes by finding a writable admin flag.

It enumerated more than 110,000 Active Directory objects from a domain controller and read the Domain Admins group. Scripts checked usernames without pre-authentication, listed group Managed Service Accounts, audited AD CS templates and mapped thousands of cross-forest principals.

4. Lateral movement and persistence

It tried Pass-the-Ticket, WinRM, Kerberos relay and Pass-the-Hash against domain controllers. In one case Windows service token limits stopped it, then endpoint protection blocked execution and defenders cut access. For persistence in the cloud it generated an SSH key pair, allocated an Elastic IP and launched t3.micro jump hosts; on the application side it reset user passwords and created administrator accounts.

5. Abuse of built-in features

One example stands out. Rather than deploy malware, ARTEX forced an application's notification system to send test emails to over 1,300 internal users, then dropped to single-recipient tests. Mandiant uses this to argue that business functions need rate and recipient limits.

How it differs from a human operator

Google lists several differences worth hunting for:

• Speed in bursts. Individual execution sequences ran roughly 2 to 25 seconds, with one case of 27 events in 23 seconds probing AWS permissions. When a script was "too large," ARTEX trimmed it and relaunched in about 10 seconds to deploy a 17-snapshot instance.
• Noise. Compared with a competent human, ARTEX reached code execution in a "forensically noisy manner," relying on iterative trial-and-error.
• Recognizable identifiers. Probe files named artex-probe-* with five-digit incrementing numbers, the same style of counter in account names, passwords and email subjects, and ArtexProbe in created account names.
• Pauses. Each intrusion still showed long pauses between phases, such as the offline password cracking wait.

Google concludes that ARTEX "trades stealth for velocity," which gives defenders something to catch, but notes that detecting an attack in time does not by itself stop the objective being met. Wiz's tracked campaign, which GTIG calls UNC7228 and which overlaps Microsoft's STORM-0940, typically moved from first compromised account to deep access in around four hours and once in 15 minutes, and falls back to open proxies when infrastructure is blocked.

PentAGI, CAIRN and where this is heading

GTIG also saw PentAGI, developed by VXControl with open source and commercial editions, which runs standard Kali tools such as Metasploit, nmap and SQLmap inside isolated sandboxes. Most observed PentAGI use stopped at WHOIS asset mapping or active scanning, but some operations reached intrusion and persistence. One customized orchestration platform built on it targeted system integrators and telecommunications firms in Asia between at least late August and early October 2026, and another chained PentAGI with proxy services against the aerospace sector.

Google lays out a seven-stage maturity model from simple prompting (late 2025) to fully autonomous, sophisticated attacks. It places the current state at stage 5, where multiple lifecycle stages run through LLM tooling with fewer humans in the loop, and expects stage 6 (multi-agent attacks with little human interaction) in the near term of 1 to 3 months. It assesses with high confidence that cybercrime actors will keep adopting these tools because wider reach compensates for lower success rates. It also notes experimentation with the ZeroHollow inference service and the AgentZero framework.

The five layers of defense Mandiant recommends

Mandiant frames the guidance as long-standing practice. The point is that automation exploits the gaps between controls faster.

Google SecOps customers get detections named Suspicious Webhook.Site Interaction, Suspicious Curl Invocation, Cmd Launching Curl and AWS Cloud Accounts Getcalleridentity. The report also warns that static indicators will miss much of this activity, because attackers use valid accounts and supported functionality.

What this means if you run AI coding agents

ARTEX does not attack coding agents. But it shows what happens to the secrets that sit in developer environments once someone has a foothold, and the stolen-key side of the story appears across our coverage of AI-led attacks in October. Practical checks:

1. Inventory long-lived keys your agents can read. Cloud access keys, storage account keys, PATs and .env files in a workspace are exactly what ARTEX tested in milliseconds. Replace them with short-lived credentials where you can, per Mandiant's layer 2.
2. Keep secrets out of agent context. An agent that can cat .env can put the output into logs, transcripts and tool calls. Check what your sessions record.
3. Rotate quickly after any exposure. Our first 24 hours runbook lays out the order.
4. Watch egress from build and dev servers. Unexpected calls to webhook services are one of the clearest ARTEX tells. Compare it with the Aur0ra case, where attackers drove Cursor agents to domain admin.
5. Search your logs for the published markers: artex-probe-* filenames, ArtexProbe account names, accounts with is_admin=true created in minutes, SET GLOBAL general_log_file pointing at .jsp paths, and t3.micro instances you did not launch.

What Beam can and cannot do here

Beam runs on a developer machine and watches what coding agents do there. It can flag credential exposure in agent actions and keeps session data on-device, with redaction before storage, so it helps with the "secrets leak through agent sessions" part of the problem. Its deny is hook-based for Claude Code and Codex PreToolUse, not a kernel sandbox, and its skill and MCP scanning is heuristic. Beam does not read Active Directory, Entra, AWS or Azure logs and cannot detect Kerberoasting, DCSync or a MySQL log webshell. Use your SIEM and the vendor detections above for those. See how Beam works and what it watches.

Related reading

• WorkOS breach: ARTEX link to a sales app, confirmed vs claimed
• October 2026 attacks timeline and the November 2026 attacks timeline
• Wiz: anatomy of an AI-driven cloud attack
• Sources: GTIG and Mandiant report, Microsoft Threat Intelligence on Storm-0940, and Cyber Security News' summary.

Frequently asked questions

What did Google and Mandiant report about ARTEX?

Google Threat Intelligence Group and Mandiant say that since late August 2026 multiple threat actors have used the open-source agentic pentesting frameworks ARTEX, PentAGI and CAIRN in incident response engagements, covering lateral movement, database exploitation and exfiltration preparation.

Is ARTEX still available after the original repository was removed?

Yes. Google says the original author took the GitHub repository down in October 2026 because of abuse, but forks keep spreading, including ScopeWeaver and a commercial version called ARTEX PRO.

How can I tell an agent framework from a human intruder?

Google points to bursts of activity lasting roughly 2 to 25 seconds, one case of 27 events in 23 seconds, rapid trial-and-error that produced 240 log events, incrementing probe names such as artex-probe-*, and calls to many rotating webhook.site URLs.

What is the single most useful defense?

Mandiant stresses limiting what a stolen identity can do: short-lived, tightly scoped credentials, trusted-network restrictions on control planes and behavioral detection. The techniques are unchanged, so these long-standing controls are what slow the automation.

Does this affect people who run AI coding agents?

Indirectly. ARTEX attacks servers, Active Directory and cloud accounts, not coding agents. But the credentials it harvests include environment variables, storage keys and tokens, which are the same secrets a coding agent session can expose.

Details are accurate as of November 2, 2026. Vendor reports are updated as investigations continue; check the linked sources for changes.