On October 30, 2026, Google Threat Intelligence Group (GTIG) and Mandiant reported observing ARTEX, PentAGI and CAIRN in incident-response cases dating back to late August. The Google report describes agents automating portions of attacks, with some rapid activity that also left conspicuous traces.
What the frameworks did in observed cases
GTIG and Mandiant describe automation across parts of the attack lifecycle, including reconnaissance, permission testing, privilege escalation, lateral movement, database activity and preparation for data theft. The underlying techniques included credential abuse and taking advantage of exposed or unpatched systems; automation let operators test and chain actions faster.
Google describes ARTEX as a multi-agent platform written in Go, with a Next.js console and six specialized agents. PentAGI, developed by VXControl, runs its tools in isolated Kali Linux sandboxes and supports more than a dozen cloud and local large language model backends. GTIG and Mandiant also named CAIRN and possible custom agent setups in their incident-response observations.
Fast activity can leave a noisy trail
GTIG and Mandiant report ARTEX activity in bursts of roughly 2 to 25 seconds, with pauses between phases. In one case, a burst generated 27 events in 23 seconds. In a separate Linux Weaver OA case, activity generated 240 log events during attempts that achieved partial command execution and reconnaissance. The report characterizes current use as early, relatively unsophisticated and noisy.
Those numbers describe individual cases, not a general measure of attack speed. Google also relayed a campaign-specific timing attributed to Wiz: the move from a first compromised account to deep system access took about four hours in typical cases and 15 minutes in one case.
Wiz reports repeated probing of software vendors
Wiz described ARTEX-associated activity targeting IT and software vendors through identity services and application interfaces, including Okta, Entra, Cognito and Microsoft 365 integrations. Its account describes repeated probing of sign-in and account-recovery flows and tests of application access. Wiz said most attempts in the activity it described failed.
That finding gives the activity a more precise shape: automation can drive persistent, rapid attempts, but the observed attempts did not routinely succeed. The vendor-targeting observations are specific to Wiz’s account, not a measure of all ARTEX use.
Five defensive layers Mandiant recommends
Mandiant’s recommendations combine controls that restrict what an intruder can reach with monitoring that can reveal unusual behavior. A control plane is the administrative layer used to manage systems and cloud resources; least privilege means giving an account only the access its role requires.
| Defensive layer | Control emphasis | Practical purpose |
| Protect control planes | Limit administrative interfaces to trusted networks | Reduce exposure of high-impact management functions |
| Restrict identities and keys | Use short-lived, workload-bound credentials and least privilege | Limit what a compromised account or key can access |
| Harden configurations and reduce attack paths | Segment internet-facing workloads and remove unnecessary routes between systems | Make it harder to move from one exposed system into others |
| Protect applications | Add safeguards around high-impact application functions | Restrict sensitive actions through application interfaces |
| Detect behavioral and volumetric change | Correlate identity, control-plane, data-plane and network activity | Surface sequences or volumes that depart from an identity’s normal pattern |
A single sign-in or API call may look legitimate on its own. Mandiant recommends looking at the surrounding sequence, volume, origin and timing, alongside the identity’s usual behavior. That makes monitoring useful alongside access controls: one limits an account’s reach, while the other can flag activity that departs from its normal pattern.
