Google Threat Intelligence Group and Mandiant published an analysis on 31 October, credited to 8 authors, of what they call agentic offensive frameworks. The headline framework is ARTEX, described as an autonomous multi-agent platform for penetration testing and command and control, written in Go with an embedded web console, splitting the attack lifecycle across 6 sub-agents.

That AI agents are being pointed at networks is not the useful part, and we have been writing it all week, most recently about a stealer that plans for the model refusing. The useful part is further down, where the report prints the telemetry.

What it looks like in a log

Read these as a detection signature rather than as a scoreboard. In observed intrusions, bursts of activity ran 2 to 25 seconds per sequence. One probing burst produced 27 events in 23 seconds. A snapshot operation deployed 17 instances in about 10 seconds. A single SQL and webserver operation generated 240 log events.

A cloud resource validation sweep covered 11 resource types in 8 seconds, and individual blob writes and deletes completed in 330 to 400 milliseconds. Endpoint fuzzing ran to over 500 web requests. Callbacks rotated through 491 separate webhook URLs.

Inside the network, one operation enumerated over 110,000 directory objects and another sent test messages to over 1,300 internal users. Credential extraction pulled roughly 400 kilobytes across about 20 queries. Storage was provisioned on the fly: a 100 gigabyte volume created, a root disk expanded to 60.

Time from intrusion to deep access was about 4 hours. In one case it was 15 minutes.

The speed is the thing that gives it away

Every number above is also a detection opportunity, and that is the part worth taking to whoever owns your alerting. No human enumerates 110,000 objects in a burst, or validates 11 cloud resource types in 8 seconds, or emails 1,300 colleagues as a test. Rate is the signal. The tooling that was too noisy to catch a careful operator is well suited to catching this.

GTIG is careful about what the counts mean, and so should anyone quoting them be. Its own words: "Based on our visibility, it is difficult to comment on the exact significance of these numbers or how they increment."

Where it has actually been used

The observed activity is specific: cloud credential mapping, abuse of a deployment and management service, Kerberoasting, credential dumping through SQL injection, directory replication, creation of an account with an administrator flag set, and a web shell built by poisoning a database log file.

One campaign was tracked by another vendor and corresponds to a cluster GTIG calls UNC7228, which overlaps with an actor Microsoft describes as PRC-nexus. GTIG also places financially motivated extortion groups and further suspected PRC-nexus clusters in the same tooling.

The second framework, PentAGI, is a separate product with open source and commercial editions, running its tools in isolated sandboxes and supporting more than a dozen model backends. Most of the PentAGI activity GTIG saw never got past asset mapping and vulnerability scanning. Some of it did reach intrusion and persistence, including a customised build used against system integrators and telecoms in Asia, and another against aerospace.

And where it failed

The report does not flatter the tooling. Some ARTEX attempts failed outright because the cloud role identifiers were invalid. Endpoint protection blocked execution in at least one engagement and defenders cut the access. Errors appeared that GTIG attributes to multiple sub-agents overwriting one another while chasing the same objective.

Its summary assessment is the sentence to keep: current adversary use of these frameworks "is still in early stages characterized by open source tools currently being used in low-sophisticated ways".

What GTIG has not seen

Fully autonomous intrusion, with no human in the loop, is not in the observed column. It appears as a forecast, split into a near-term stage GTIG puts at 1 to 3 months and a medium-term stage at 3 to 6 months. Those are predictions by the authors, not things they watched happen.

GTIG also notes that actors who specialise in quiet long-term access are less likely to use the public versions of these tools, which is a reminder that the loud activity in this report is the activity that was visible.

What to do

  • Take the rates to your detection team as thresholds. Objects enumerated per minute, requests per second against unknown endpoints, cloud API calls per second from one principal.
  • Alert on outbound callbacks to request-capture and webhook services. 491 rotating URLs from one operation is not a thing a normal workload does.
  • Watch for storage and compute created and destroyed inside minutes, which is how the data collection here was staged.
  • Keep the account creation and directory replication detections you already have. The agent used ordinary techniques quickly, not new ones.
  • Do not reclassify this as unstoppable. In this report it was blocked by endpoint protection, broke on bad identifiers, and tripped over its own sub-agents.

What is not established

  • How effective these frameworks are overall. GTIG saw engagements, not a success rate.
  • Who is behind most of the activity. One cluster is named, others are suspected.
  • Whether the forecast stages arrive on the stated timeline. Both are assessments.
  • What the counts mean in aggregate. GTIG says plainly that its visibility does not support that reading.
  • Whether sophisticated actors are using private versions. GTIG suspects they would not use the public ones.
  • Which models are behind any of it. The report describes frontier and open-weight backends without naming them.