Threat actors are now running open-source, multi-agent penetration testing frameworks inside real intrusions. On 30 October 2026, Google Threat Intelligence Group (GTIG) and Mandiant published ARTEX and Friends: Enter Agentic Offensive Frameworks, reporting that since late August 2026 they have observed attackers operating ARTEX, PentAGI, CAIRN and possibly custom harnesses within Mandiant incident response engagements. The agents carried out significant parts of the attack lifecycle, including lateral movement, database exploitation and preparation for exfiltration. Individual ARTEX execution sequences ran in bursts of roughly 2 to 25 seconds, and in one operation Google counted 27 events in 23 seconds of active burst time.
Quick answer: ARTEX is an open-source, multi-agent, LLM-driven penetration testing and command-and-control platform. Google says it has been adopted since late August 2026 by financially motivated extortion groups and suspected cyber espionage operators. The techniques are familiar: stolen credentials, Kerberoasting, DCSync, cloud key harvesting, webshells. The change is that an agent chains them in seconds and minutes. Google assesses that current use is early, broad and forensically noisy but still successful, and writes that such frameworks "currently trade stealth for velocity". Mandiant's answer is five defensive layers, and the question for a penetration test or red team engagement becomes how far one stolen credential gets and whether detection and containment act within minutes.
This analysis rests on four primary reports, plus ConnectWise's own advisory and MITRE ATT&CK for detection guidance, read as of 12 November 2026: Google's 30 October report, GTIG's AI Threat Tracker of 8 September 2026, Microsoft Threat Intelligence's 21 October 2026 report on Storm-0940, and CrowdStrike's 7 October 2026 report on ARTEX use against South Korean financial organizations. Each statement below is marked as observed (seen by the named publisher in incident response or telemetry) or assessed (that publisher's judgement or forecast). No figure appears here that those documents do not give, and every one is linked to its publisher so any claim can be checked.
Key facts at a glance
Fact | Who says it | Status |
|---|---|---|
Attackers have operated ARTEX, PentAGI, CAIRN and possibly custom harnesses in Mandiant incident response engagements since late August 2026 | Google (GTIG and Mandiant), 30 Oct 2026 | Observed |
ARTEX adopters include financially motivated extortion groups and suspected cyber espionage operators | Observed | |
An ARTEX campaign that GTIG tracks as UNC7228 overlaps with the actor Microsoft tracks as Storm-0940 | Google (overlap); Microsoft, 21 Oct 2026 (Storm-0940 profile) | Google's attribution |
ARTEX execution sequences ran in bursts of roughly 2 to 25 seconds; 27 events in 23 seconds in one operation | Observed | |
Storm-0940 went from initial targeting to privileged cloud access in less than 3 hours in multiple instances | Microsoft | Observed |
One ARTEX code execution attempt generated 240 log events | Observed | |
Adversary use of autonomous offensive frameworks is still at an early stage: unsophisticated, broad and noisy, but successful | Assessed | |
Cyber crime actors will continue incorporating autonomous offensive tools | GTIG | Assessed, high confidence |
Unsophisticated multi-agent attacks with little to no human interaction | Expected, near term (1 to 3 months) | |
Sophisticated, stealthy, fully autonomous attacks | Expected, medium term (3 to 6 months) |
What Google reported on 30 October 2026
The report is a joint publication by GTIG and Mandiant, and it is a follow-up. In its AI Threat Tracker of 8 September 2026, GTIG said forward-leaning adversaries were moving from basic prompting to agentic workflows and AI-enabled automation. That earlier report described a suspected financially motivated actor who compromised an organization's cloud infrastructure and then planned, built and executed a mass credential harvesting campaign with a bespoke multi-agent framework in less than six hours, and an exposed command-and-control server whose dashboard managed over 23,800 harvested secrets. It also described a PRC-nexus espionage group trying to design an automated penetration testing framework, and GTIG was explicit that this activity was limited to attempts to build it.
Seven weeks later the status had changed. Google's October report says the frameworks are no longer only being built or tested. They are succeeding in intrusions, and Google has seen them in two places: Mandiant incident response engagements and its own research telemetry.
Three points in the report deserve exact reading.
Which frameworks. The introduction names ARTEX, Hexstrike and CAIRN as the open-source agentic pentesting frameworks abused in incident response engagements. The observations section names ARTEX, PentAGI, CAIRN and other potentially custom harnesses. The report then describes only ARTEX and PentAGI in detail. It gives no technical description of CAIRN or Hexstrike, so this post does not add one.
What the agents did. Google observed agentic activity conducting significant parts of the attack lifecycle and gives lateral movement, database exploitation and exfiltration preparation as examples. It does not claim a fully autonomous intrusion from start to finish. In several cases, it says, the adversary supplied ARTEX with compromised credentials for the target and instructed the framework to carry out the following stages.
What has not changed. Google states that the mechanics of these intrusions are the same as before, such as using compromised credentials and targeting unpatched systems. The new problem is the speed and scale at which a framework exploits those known weaknesses.
Google places this in a long tradition of attackers adopting tools built for security professionals, and names Cobalt Strike and Metasploit as the earlier examples. An agentic framework is the same dual-use problem with a planner attached.
What ARTEX is
Google describes ARTEX as an autonomous, multi-agent, LLM-driven pentesting and offensive command-and-control (C2) platform, written in Go with an embedded Next.js web console. It was released on GitHub by an individual developer. Google reports that the creator took the original repository down in October 2026 because of widespread threat actor abuse, and that the framework continues to spread through community forks, including localized variations such as ScopeWeaver and a commercial version called ARTEX PRO.
According to Google, ARTEX splits the attack lifecycle across six specialized sub-agents and uses the APIs of frontier and open-source models to turn a high-level goal into machine commands. The capabilities GTIG has observed include automated Active Directory reconnaissance, privilege escalation, profiling of a target's cloud infrastructure (such as harvesting Azure storage keys), and writing and deploying custom webshells.
Microsoft's report adds three details. ARTEX can use any AI model. Its agents collect the assets and vulnerabilities they discover into a graph as the test proceeds. And although the interface defaults to English, it can be switched to Korean, Mandarin, Spanish or Japanese. Microsoft describes it as a system of LLM-driven agents that runs a penetration test from reconnaissance through data exfiltration with little human interaction.
CrowdStrike's report calls ARTEX a recently released open-source agentic penetration testing tool developed in China. In the infrastructure CrowdStrike analysed, the ARTEX instance used a DeepSeek model as its primary LLM backend, likely reached through an API proxy or reseller. That is consistent with a trend Google describes at its current stage: operators experimenting with ways to obscure their model usage and reduce reliance on frontier-lab models.
PentAGI, CAIRN and Hexstrike
PentAGI (Penetration Testing Artificial General Intelligence) is the second framework Google describes. It is developed by VXControl, offered in open-source and commercial editions, and designed so that a user only needs to describe a target and a goal. A team of specialized agents breaks the task into sub-tasks and runs open-source tools that ship with Kali Linux inside isolated sandboxes. It supports more than a dozen cloud and local LLM backends.
Google's observations of PentAGI are more modest than those of ARTEX. Most observed PentAGI activity stayed at WHOIS asset mapping or active vulnerability scanning. Some operations did progress to active intrusions and persistence across multiple organizations. Google also identified a customized attack orchestration platform built on the open-source edition, likely used between at least late August and early October 2026 for systematic reconnaissance and vulnerability scanning against organizations in Asia, including system integrators and major telecommunications firms, and one instance of PentAGI chained with proxy services to target the aerospace sector.
CAIRN and Hexstrike are named in the report and not described further. Google also notes evidence of threat actors experimenting with an inference service called ZeroHollow and with the fully agentic framework AgentZero.
Who is using these frameworks
Google's wording is that ARTEX has been adopted since late August 2026 by a diverse range of threat actors across the motivational spectrum. Three groups of evidence sit behind that sentence.
A PRC-nexus campaign. Google says an ARTEX campaign that GTIG tracks as UNC7228 overlaps with activity Microsoft tracks as Storm-0940, which Google calls a PRC-nexus actor and Microsoft calls a China-state aligned actor active since 2021. Microsoft reports that, as early as September 2026, Storm-0940 used ARTEX to automate attacks targeting hundreds of organizations globally, and that several of those attacks ended with privileged access to an organization's cloud infrastructure, in multiple instances less than 3 hours after initial targeting. Microsoft also assesses that Storm-0940 was responsible for the supply chain compromise of a multi-tenant application disclosed by ConnectWise, whose advisory, first published on 16 October 2026, reports unauthorized access to application credentials associated with its Cloud Backup product. After that access, Microsoft says, the actor used ARTEX to attempt sign-ins to more than 2,250 downstream tenants, and in some of them the agents went on to Microsoft Graph and directory operations: reconnaissance, application credential changes to establish persistence, and changes to identities, groups and privileged roles.
Microsoft's caveats belong next to those numbers. The majority of the targeting was not successful. An affected application, or even a successful sign-in by the actor, does not by itself mean customer data was accessed or exfiltrated. And the activity did not result from a compromise of, or a vulnerability in, Microsoft's own systems, products or services.
Extortion actors and further suspected PRC-nexus clusters. In its own incident response investigations, Google observed multiple other threat actors using ARTEX for post-compromise reconnaissance, lateral movement and privilege escalation. These included financially motivated actors who used the framework to facilitate data theft extortion, and additional suspected PRC-nexus clusters. Together, Google says, their operations affected organizations in the government, technology, chemicals and materials, and manufacturing sectors in the United States.
A financially motivated actor in Asia. Google points to public reporting of ARTEX targeting the financial sector in Asia. That reporting is CrowdStrike's: a campaign against South Korean financial organizations, active from late September to early October 2026, that resulted in exfiltrated data. CrowdStrike has not attributed it to a named adversary and assesses with moderate confidence that the actor is likely a Chinese speaker and financially motivated.
Microsoft says Storm-0940 used ARTEX to accelerate scanning and reconnaissance, password spraying and OAuth application abuse, and one episode in its report is a useful picture of the noise that automation produces. Between 10 and 14 October 2026, infrastructure Microsoft attributes to Storm-0940 ran an automated cross-tenant password spray against 327 accounts in eight organizations. Microsoft's telemetry recorded more than 151,000 failed logons, peaking at 2,900 failures per minute on 11 October, and no successful authentication. The spray failed. The access that followed came through a trusted third-party application instead.
What the agents did, phase by phase
Google maps the ARTEX activity it observed to the phases of Mandiant's targeted attack lifecycle. The table below condenses that mapping. It covers Azure, AWS and on-premises Active Directory activity, and Google does not say whether it comes from one intrusion or several.
Phase | What Google observed ARTEX do | What it tells a defender |
|---|---|---|
Initial recon | Mapped the effective permissions of obtained Azure credentials (SAS tokens, service principals, Kudu credentials, storage account keys) with sub-second capability checks, test blob writes and deletes, and deployment validation dry runs. Tested a compromised AWS IAM user with dry-run flags and placeholder IDs. Sent over 500 web requests probing file names and extensions on a web server. | A stolen key is tested for everything it can do within seconds, without creating anything that looks like damage. |
Establish foothold | Abused Kudu administrative APIs to run commands and stage scripts. On an internal Windows database server, used the native curl client to fetch generated PowerShell and batch scripts and to post results across 491 rotating webhook.site URLs. | Management interfaces and outbound web access from servers are the foothold. The tooling was generated scripts and the server's own curl client, not a pre-built implant. |
Escalate privileges | Ran Kerberoasting scripts across compromised domains, used SQL injection to dump database credentials and, after a pause for offline cracking, ran DCSync scripts to take the domain krbtgt key, cloud directory sync credentials and domain controller machine hashes. Created accounts flagged as administrators within minutes by finding a writable admin flag. An attempt to launch cloud instances with high-value IAM roles appears to have failed because the instance profile ARNs were invalid. | The classic Active Directory path from service account to domain compromise was run by the framework's own scripts, with a pause for offline cracking. An application-level access control flaw is found and used just as quickly. |
Internal recon | Ran iteratively generated PowerShell enumeration against a domain controller and a federation server: validated domain usernames without pre-authentication, listed Group Managed Service Accounts, audited AD CS certificate templates, mapped thousands of cross-forest security principals and swept internal Exchange, a PasswordState credential vault, and SSRF and SCM targets. | The agent reads identity infrastructure the way an experienced tester does, and it looks for the credential vault. |
Move laterally | Attempted to reach domain controllers with Pass-the-Ticket, WinRM, Kerberos relay and Pass-the-Hash scripts. It hit Windows service token privilege restrictions just before endpoint protection blocked execution and defenders cut access to the server. | Controls and responders stopped this attempt. Hardening and fast containment still work. |
Maintain presence | Generated an SSH key pair, allocated a public Elastic IP and launched persistent t3.micro instances on existing security groups as a jump host, after failing to create its own security group for lack of permission. Reset passwords, created multiple accounts with plaintext passwords and created administrator accounts. | Persistence is ordinary account and cloud resource creation. It is visible in identity and control-plane logs if someone is watching them. |
Complete mission | Queried backend SQL databases (about 400 KB of results across about 20 queries), performed mass blob reads, enumerated over 110,000 Active Directory objects and retrieved the Domain Admins group, sending output to rotating webhook endpoints. Created a 100GB volume and expanded root disks to 60GB, likely in preparation for exfiltration. Made an application's notification system broadcast test emails to over 1,300 internal users. | Data staging uses the victim's own cloud capacity. A trusted internal messaging feature becomes a distribution channel. |
Two of Google's observations are worth isolating because they are easy to miss in a list of techniques.
The first is abuse of legitimate features. In the notification case, Google points out that ARTEX did not deploy complex malware. It weaponized a built-in application feature. Mandiant's later guidance makes the general point: internal applications, scripts and APIs are customized to each organization and usually undocumented, and LLM-powered tooling lets an attacker enumerate and understand them quickly.
The second is the crossing from data to system. In one intrusion, ARTEX, working with a valid user credential on an internet-facing web application, used an application-specific SQL API to change database logging settings so that log files would be written as server-side script files in a web-accessible location. Google judges that this was likely intended to plant webshells. It took the agent several attempts with different file names, correcting its own errors each time, until the scripts ran cleanly and returned command output.
How fast, and how noisy
The timings in Google's report are measured in seconds. Google identified bursts of activity that would be highly irregular for a human operator. Each intrusion still showed extended pauses during its operational phases, so a whole intrusion is not a matter of seconds, but once an execution sequence starts the agent does not stop to think for long.
Activity | Time | Source |
|---|---|---|
Write and immediately delete a small test blob to confirm storage permissions | About 330 to 400 milliseconds | |
Deployment validation dry-run sweep across 11 Azure resource types | 8 seconds | |
Deploy a 17-snapshot instance after trimming a script the platform rejected as too large | About 10 seconds | |
27 events probing AWS permissions across security groups | 23 seconds of active burst time | |
Individual ARTEX execution sequences | Roughly 2 to 25 seconds | |
Initial targeting to privileged cloud access (Storm-0940, multiple instances) | Less than 3 hours | Microsoft |
Plan, build and execute a credential harvesting campaign with a bespoke agent framework (Q2 2026) | Less than six hours | Google, 8 Sep 2026 report |
The other half of the picture is noise. Google's comparison is with a competent human operator, and ARTEX comes off worse on stealth:
Trial and error leaves a trail. Achieving partial command execution on one web server generated 240 log events, with errors that Google thinks may have been caused by multiple sub-agents overwriting one another while pursuing the same objective.
Recognizable markers. Google saw probe files whose names begin with
artex-probe-followed by five-digit, roughly incremental numbers, and created accounts with ArtexProbe in the naming convention. Similar incremental numeric markers appeared in dropped file names, account names, passwords and email subjects. Forks can change these strings, so treat them as a hunting lead and not as a durable signature.Outbound callbacks. Command output went to hundreds of rotating webhook.site URLs through curl. The Google Security Operations rules that the report lists for this activity include detections for webhook.site interaction and for suspicious curl invocation.
Google draws two conclusions from this. Unrestricted autonomous execution generates forensic traffic, relies on recognizable identifiers and leaves code-level traces, which raises the chance of detection, so these tools currently suit scenarios where the cost of being detected is low. And detecting an attack is a different function from disrupting it: seeing the activity in time does little if the objective is completed before anyone responds. Microsoft makes the same point about Storm-0940. The automated activity produced a large volume of traffic and log data that may raise alerts, but its speed left defenders very little time to act on them in a coordinated way.
For a security team, that moves the useful metric. The question is less whether the SOC would eventually see an ARTEX-style intrusion, since Google's evidence is that the current tooling is loud. It is whether containment happens before the agent reaches the domain controller or the storage account. Our detection and response benchmarks for red team exercises explain how to measure that interval.
Google's seven stages, and where we are now
Google sets out seven stages to describe how adversary use of LLMs has evolved over the last year and how it expects that to continue. The first five are observation. The last two are forecast.
Stage | What it means | Google's timeframe |
|---|---|---|
1. Prompt-based use of LLMs | Chatbot-style prompting to write and debug malware code, draft phishing emails, create personas and do light reconnaissance | End of 2025 to early 2026 |
2. LLM capabilities embedded in malware | Malware families such as HONESTCUE or PROMPTSPY call an LLM during execution, for example to obfuscate payloads in different ways | Early 2026 |
3. LLM-enabled automation in operations | Agents take on discrete tasks next to human operators, including exploit development and vulnerability research; operators start using LLM-proxy services to hide their usage | Early 2026 to September 2026 |
4. Developing and experimenting with autonomous frameworks | Campaigns offload more lifecycle stages to LLM-driven tooling and wire model APIs into tools and Telegram bots | Mid 2026 to September 2026 |
5. Multiple lifecycle stages run by LLM-driven tooling in the wild | Mass-exploitation campaigns where an agent carries out a substantial part of the lifecycle with minimal human intervention; tactics remain messy and noisy, yet successful | Current stage of development |
6. Multi-agent, unsophisticated attacks with little to no human interaction | The adversary defines the target and objective; a multi-agent framework executes the whole chain. Still forensically noisy | Near term (1 to 3 months) |
7. Sophisticated, fully autonomous attacks | Little to no human interaction plus greater stealth, with operators reaching LLMs through obscure infrastructure or self-hosted models | Medium term (3 to 6 months) |
The forecast comes with stated confidence. GTIG says it assesses with high confidence that cyber crime actors will keep incorporating autonomous offensive tools, because the wider reach of their campaigns is likely to compensate for lower success rates. It expects actors who specialize in stealthy, long-term access to be less likely to use the publicly available versions, though they may still use them where scale and speed matter more. It calls continued growth in adoption highly likely in the near term, citing the low barrier to entry, the ease of adding new exploits and the scaling potential.
Stages 6 and 7 are expectations that Google stated on 30 October 2026, not events. Nothing in the report says a fully autonomous, stealthy intrusion has been observed. For how earlier milestones in this progression translate into test cases, see our mapping of 2026's AI-attacker milestones to red team coverage and the account of the Hugging Face intrusion.
What changes for defenders, and what does not
Mandiant's section of the report opens with the sentence that should set priorities: LLM-enabled offensive tooling does not fundamentally change the techniques attackers use, it reduces the time required to combine them. Credential discovery, permission testing, lateral movement and data access that used to take an operator hours can now happen in minutes.
Mandiant lists four themes that recur in its investigations of LLM-enabled or highly automated activity:
Speed and scale. Automated tooling performs broad reconnaissance, tests several attack paths at once, reacts to failures and continues straight into follow-on activity. The time between initial access, privilege discovery, lateral movement and data access can become very short.
Interconnected environments. An internet-facing application exposes a credential in a configuration file, and that credential reaches cloud storage, source repositories, identity systems or internal infrastructure. Automation makes those relationships quick to find and test.
Legitimate-looking identity activity. A service principal authenticates, an API is called, a storage object is downloaded. Each action looks normal alone. The signal is in the context: origin, volume, what happened just before and after, and whether the behavior is expected for that identity.
Control-plane and data-plane blind spots. Many organizations have mature endpoint monitoring and much less visibility into management APIs, programmatic identities and cloud storage activity. Permission testing, storage key retrieval, bulk downloads and firewall changes may all be logged without producing a useful alert.
The practical consequence is that static indicators carry less of the load. Mandiant notes that much of this activity uses valid credentials and supported functionality, so tool names, hashes and IP addresses help when available but will not cover most of it. It asks for two capabilities together: controls that limit what an attacker can do after gaining valid access, and telemetry that shows when an identity, application or workload starts operating outside its normal pattern.
One detail in the guidance is new enough to underline. Error messages are now attacker feedback. Mandiant observes that an application error, stack trace, database response or API error can give the tooling enough information to change its next request within seconds, so detailed diagnostics shown to external users speed up an attack as well as a support call.
Mandiant's five layers of defense
Mandiant recommends structuring defenses in five layers, designed to restrict lateral movement and limit the speed advantage of autonomous tooling. Google is direct that these are long-standing practices. The difference, Mandiant says, is that automated tooling can now find and exploit the gaps between those controls much faster.
Layer | Mandiant's summary | Selected mitigations from the report |
|---|---|---|
1. Protect control planes | Restrict all admin APIs, consoles and CI/CD to trusted networks | Remove internet exposure of cloud administration, device management, publishing interfaces, hypervisors and backup platforms. Require managed devices or privileged access workstations with phishing-resistant authentication. Treat application publishing endpoints such as Kudu/SCM as privileged infrastructure and disable basic publishing authentication where it is not needed. Alert on administrative access from unseen networks, hosting providers or geographies. |
2. Restrict identities and keys | Migrate to short-lived workload credentials; eliminate secrets | Replace static AWS IAM access keys with roles, Azure service principal secrets with managed identities, and long-lived Google Cloud service account keys with Workload Identity Federation. Disallow Azure Storage shared key authentication in favor of Entra ID authorization. Restrict where non-human identities can authenticate from, not only what they can reach. Isolate password vaults and secret stores. Monitor bursts of password resets and account creation. |
3. Harden configurations and reduce attack paths | Continuous vulnerability scanning across applications and infrastructure | Segment internet-facing applications from identity infrastructure. Limit database accounts so they cannot write arbitrary files, change server-wide settings or run operating system commands. Stop returning stack traces and SQL errors to external users. Review AD CS templates and enrollment permissions. Enforce SMB signing, LDAP signing and channel binding, and reduce NTLM. |
4. Application protections | Harden applications to prevent abuse of legitimate features | Put rate limits, recipient limits and transaction thresholds on APIs that send email or notifications, create users, change access or retrieve credentials. Inventory which platforms can execute remote commands, deploy code, issue certificates or send bulk messages before an incident. Run SAST and DAST on internal applications before deployment. |
5. Detect behavioral and volumetric change | Monitor identity velocity, API bursts and volumetric anomalies | Baseline each sensitive identity and workload. Alert on new authentication origins and on bursts of management API calls, permission testing and credential retrieval. Correlate sequences across identity, control-plane, data-plane, endpoint and network telemetry. Restrict server egress and watch for new destinations such as webhook services, tunneling platforms and external AI platforms. |
Two cautions from Mandiant apply to the detection work. In its guidance on secret stores it notes that detections for bulk secret queries and enumeration overlap with legitimate automation, so the signal is in the identity, origin, volume and sequence, and known-good automation has to be baselined first or routine activity will raise false positives. And for the fifth layer, a baseline needs history: identity logs for interactive and non-interactive sign-ins, service principal authentication, cloud control-plane activity, storage data-plane logs, network flow, DNS and proxy telemetry all have to be collected before the incident.
In the fourth layer Mandiant also recommends turning the same technology around: using LLM-enabled tooling, including agentic source-code review and continuous AI-assisted vulnerability testing, to find, triage and reproduce attack paths before an attacker does.
What a penetration test or red team engagement should now cover
A penetration test that only lists vulnerabilities by severity does not answer the question the Google report raises. That question is about chains and time: starting from one valid credential, how far does an automated attacker get, how quickly, and at which step does someone stop it. The table translates the observed behavior into test objectives. The ATT&CK technique references are our mapping, added so findings can be tied to detection engineering. Google's report does not use them, and Microsoft publishes its own mapping for Storm-0940.
Test objective | Observed behavior it answers | What the report should show |
|---|---|---|
Assumed breach from one valid credential, timed | Operators supplied ARTEX with compromised credentials and let it run the following stages (Google) | The furthest point reached, with timestamps for each milestone, the first alert and the moment of containment |
Kerberoasting exposure (T1558.003) | Kerberoasting scripts across compromised domains, then offline cracking (Google) | Which service accounts have crackable passwords and privileged rights, and whether the burst of service ticket requests raised an alert |
DCSync and replication rights (T1003.006) | DCSync used to take the krbtgt key, directory sync credentials and domain controller machine hashes (Google) | Every principal other than a domain controller that holds replication rights, and whether replication requested from a non-DC host is detected |
AD CS, relay and reuse of tickets and hashes (T1649, T1550.002, T1550.003) | Certificate templates audited; Pass-the-Ticket, Pass-the-Hash, Kerberos relay and WinRM attempted against domain controllers (Google) | Exploitable templates and enrollment paths, the state of SMB signing, LDAP signing and channel binding, and which attempts endpoint protection blocked |
Cloud key harvesting and permission probing (T1078.004, T1580) | SAS tokens, service principals, publishing credentials and storage account keys tested with dry runs and test writes in seconds (Google) | Where long-lived keys are stored, what each one reaches and from which networks, and whether a burst of dry-run calls appears in any alert |
Control-plane exposure | Kudu administrative APIs used to run commands and stage scripts (Google) | Every management interface reachable from the internet or from an application tier, with the authentication it accepts |
Database-to-system boundary (T1505.003) | Application database access used to change logging settings and write server-side script files to a web path (Google) | Whether the application's database account can change server settings or write files, and whether new script files in web directories are detected |
Application authorization and feature abuse | A writable admin flag used to create administrator accounts; a notification feature made to email over 1,300 users (Google) | Broken access control and business logic findings in internal as well as public applications, and the rate and recipient limits on high-impact functions |
Stolen application credentials used to sign in to customer tenants and add credentials for persistence (Microsoft) | Which multi-tenant applications hold high-privilege permissions, and whether credential additions to an application or service principal are alerted | |
Server egress (T1567.004) | Command output posted to rotating webhook.site URLs through curl (Google) | Which servers can reach arbitrary internet destinations, and whether first-seen destinations from production servers are flagged |
Four practices make those objectives meaningful.
Run the Active Directory and cloud paths end to end. The escalation Google describes, from Kerberoasting through cracking to DCSync, is the standard route a human tester takes in an Active Directory security assessment, and our write-up of StingAD shows the same route from a single low-privileged account. What changes is the assumption about time. A finding that used to be rated on how hard the chain is should now also be rated on how few steps it has, because each step costs an agent seconds. The cloud equivalent is the path from a harvested key to the control plane, covered in our guides to cloud penetration testing and non-human identity attacks and leaked API keys.
Put the management plane in scope. Kudu, CI/CD, backup consoles, hypervisors and firewall administration are often excluded from an application or network test because they belong to another team. They are the first layer in Mandiant's model, and we set out the usual gaps in the management plane you left out of scope.
Measure detection with the SOC, not after it. For detection of Kerberoasting, MITRE's guidance is to watch for Kerberos service ticket requests (Event ID 4769) using RC4 encryption and for accounts requesting an unusual number of service tickets in a short period, and for DCSync to watch for replication operations invoked from endpoints that are not domain controllers. An agent working by rapid trial and error is likely to make both patterns louder than a careful human operator would. A purple team exercise replays the chain at automated tempo and records, for each step, whether telemetry existed, whether an alert fired and how long a person took to act. Mandiant's fifth layer gives the detection list to test against: identity velocity, API bursts, new authentication origins, write-read-delete sequences on storage, and first-seen egress destinations.
Test the response clock. Google's distinction between detection and disruption is the most uncomfortable part of the report. Ask the red team to record time to containment alongside time to detection, and compare it with the timings above. If isolating a host or disabling a service principal needs a ticket and an approval, the engagement should say how many minutes that added. An assumed breach engagement is the most direct way to run this, because it starts where Google's cases started: with a working credential.
None of this requires the testers to use ARTEX. The point is to reproduce the conditions: valid credentials, parallel paths, no waiting between steps. Our earlier pieces on what an autonomous AI attacker can and cannot do and on the agentic layer missing from MITRE ATT&CK cover the capability side in more depth.
Defender checklist
This week
Hunt for the published markers. Search for files whose names begin with
artex-probe-, for accounts containing ArtexProbe, for curl launched from command shells on servers, and for server connections to webhook.site. Microsoft publishes indicators and hunting queries in its report, and CrowdStrike publishes indicators. Absence of these strings proves little, because forks can rename them.List every management interface reachable from the internet. Include application publishing endpoints, firewall and VPN administration, hypervisors, backup platforms and CI/CD. Restrict each to trusted networks or remove it.
Inventory long-lived keys. Storage account keys, SAS tokens, service principal secrets, static IAM access keys and personal access tokens. Rotate anything found in code, configuration or a database.
Review third-party application access. Check service principal sign-ins, new credentials on applications, consent grants and privileged role assignments, as Microsoft advises for the Storm-0940 activity.
Confirm the logs exist. Non-interactive and service principal sign-ins, cloud control-plane activity and storage data-plane logs are the ones most often missing.
This quarter
Shorten credential lifetimes. Move workloads to roles, managed identities and workload identity federation, and restrict where each non-human identity can authenticate from.
Close the Active Directory shortcuts. Reset or migrate Kerberoastable service accounts to managed service accounts, review replication rights and AD CS templates, and enforce SMB signing, LDAP signing and channel binding.
Segment and de-privilege application tiers. Internet-facing servers should not initiate Kerberos, LDAP, SMB, WinRM or RDP to systems that do not need it, and application database accounts should not hold administrative or file-write privileges.
Stop feeding errors to the outside. Keep stack traces, SQL errors and internal paths in internal logs.
Limit high-impact business functions. Add rate, recipient and volume limits to notification, email, user creation and access change functions.
Build sequence detections. A new authentication origin followed by permission probing, enumeration, bulk download and a first-seen external destination should be one alert, not five ignored events.
Rehearse containment at speed. Set a containment target in minutes for a compromised service principal and a compromised server, decide in advance which isolation actions can run without approval, and test the target in a purple team exercise.
Commission an assumed breach test that covers the objectives in the table above and reports elapsed time for each step.
Where Stingrai fits
Stingrai is a CREST-accredited penetration testing company, accredited for both Penetration Testing and AI-Enabled Penetration Testing, offering fully human-led and hybrid (human penetration testers plus AI agents) penetration tests, delivered by experienced penetration testers who are also world-class security researchers and bug bounty hunters, with OSCE³, OSWE, OSEP and CREST CRT certifications across the team. Founded in Toronto, Canada in 2021, it works with companies from startups to enterprises across web, API, mobile, AI and LLM, cloud, network, Active Directory and social engineering penetration tests and red team engagements.
The scenarios in Google's report map to specific Stingrai engagements:
Red teaming and assumed breach. Red team engagements run as assumed breach, full-chain black box or threat intelligence-led scenarios, on-premises and in the cloud, staffed by two named penetration testers from a team with 18 published CVEs and reviewed by the team lead. An assumed breach scenario starts from a supplied credential and reports how far it reaches.
Active Directory. The Active Directory security assessment works through misconfigurations, ACL abuse, Kerberos and delegation attack paths and AD CS toward Domain Admin, which is the Kerberoasting-to-DCSync route described above.
Cloud. Cloud penetration testing covers AWS, Azure and Entra ID, and Google Cloud from control plane to workload: cross-account role assumption, storage and resource policies, instance metadata abuse, app registrations, service principals, consent grants and service account impersonation chains.
Purple teaming. Purple team exercises replay real-world techniques with your SOC, so identity velocity, API burst and egress detections are tested against the activity they are meant to catch.
Web applications and APIs. Application-layer weaknesses such as a writable admin flag are broken authorization and business logic flaws. Stingrai tests these in human-led web application penetration tests and in hybrid tests, where Snipe, Stingrai's autonomous AI agent for web applications and associated APIs, works alongside the penetration testers.
Findings are posted to the PTaaS platform as they are confirmed, each with a proof of concept and remediation guidance, and retesting of fixed findings is included. Engagements run as one-time annual tests or as continuous programs. Red team, network, Active Directory and cloud work is scoped per engagement. Stingrai's published fixed prices cover one web application and associated APIs: the Autonomous Pentest is US$3,000 one-time or US$650 a month on a 12-month plan, and the Hybrid Pentest is US$6,800 one-time or US$1,275 a month (pricing).
Frequently Asked Questions
What is ARTEX?
ARTEX is an open-source, autonomous, multi-agent penetration testing and command-and-control framework driven by large language models. Google describes it as written in Go with an embedded Next.js web console and built around six specialized sub-agents that turn a high-level goal into commands. Google and Mandiant reported on 30 October 2026 that threat actors have used it in real intrusions since late August 2026.
What are agentic offensive frameworks?
Agentic offensive frameworks are tools in which LLM-driven agents plan and carry out stages of an attack, such as reconnaissance, privilege escalation and lateral movement, with limited human direction. Most were built for penetration testing. Google's 30 October 2026 report names ARTEX, PentAGI, CAIRN and Hexstrike as open-source examples that threat actors have abused, and notes that some actors may be running custom harnesses.
Who is using ARTEX in attacks?
Google says ARTEX has been adopted by financially motivated extortion groups and suspected cyber espionage operators. An ARTEX campaign that Google tracks as UNC7228 overlaps with Storm-0940, which Microsoft describes as a China-state aligned actor that used ARTEX against hundreds of organizations from as early as September 2026. CrowdStrike reported a separate, unattributed and likely financially motivated actor using ARTEX against South Korean financial organizations.
How fast do ARTEX-driven intrusions move?
Google observed individual ARTEX execution sequences running in bursts of roughly 2 to 25 seconds, including 27 events in 23 seconds while probing AWS permissions, with extended pauses during operational phases. Microsoft reports that Storm-0940 went from initial targeting to privileged cloud access in less than 3 hours in multiple instances.
Is ARTEX activity hard to detect?
Not at present. Google found ARTEX far noisier than a competent human operator: one partial command execution generated 240 log events, and the framework left recognizable file and account names. Google says these frameworks currently trade stealth for velocity. The harder problem is response, because the agent can finish its objective before anyone acts on the alert.
Does ARTEX use new attack techniques?
No. Google states that the mechanics of these intrusions remain the same, such as compromised credentials and unpatched systems, and Mandiant says LLM-enabled tooling reduces the time needed to combine known techniques. The observed activity includes Kerberoasting, DCSync, cloud permission probing, webshell deployment and abuse of legitimate application features.
What are Mandiant's five layers of defense against AI-enabled attacks?
The five layers are: protect control planes, restrict identities and keys, harden configurations and reduce attack paths, apply application protections, and detect behavioral and volumetric change. Mandiant describes them as long-standing practices that limit lateral movement and reduce the speed advantage of autonomous tooling.
Will attacks become fully autonomous?
Google expects so, but has not observed it yet. Its report places current activity at the fifth of seven stages. It expects unsophisticated multi-agent attacks with little to no human interaction in the near term, which it gives as 1 to 3 months, and sophisticated, stealthier, fully autonomous attacks in the medium term, 3 to 6 months. The report is dated 30 October 2026, and these are forecasts, not observations.
What should a penetration test cover after the ARTEX report?
It should start from one valid credential and measure how far and how fast an attacker gets: Kerberoasting and DCSync paths in Active Directory, AD CS templates, cloud key harvesting and permission probing, exposed management interfaces, application authorization flaws and server egress. It should also record time to detection and time to containment, ideally in a purple team exercise with the SOC.
Related reading
Agentic AI Security (2026): Threats, Controls and How to Test an Agent
Inside Agentic Red Teaming: The 24/7 AI Attacker, and What It Still Cannot Do
From Headline to Test Case: Mapping 2026's AI-Attacker Milestones to Red Team Coverage
Anthropic Mapped a Year of AI Attacks to MITRE ATT&CK and Found the Layer It Is Missing
Inside the Hugging Face Breach: The First End-to-End AI-Run Intrusion
Will Your SOC Catch a Red Team? Detection and Response Benchmarks for 2026
Kerberoasting Explained: How the Attack Works, Detection and Fixes (2026)
Password Spraying: How the Attack Works, Detection and Defense (2026)
PentAGI, Shannon, Strix and Cairn: Open-Source AI Pentest Agents Compared (2026)
Purple Team vs Red Team vs Penetration Test: How to Choose in 2026
Lateral Movement Explained: Attack Paths, Detection and Testing (2026)
Red Teaming: What It Is, How an Engagement Runs and When You Need One (2026)
Best Adversary Simulation and Red Teaming Companies in 2026: 12 Providers Compared
References
Google Threat Intelligence Group and Mandiant. ARTEX and Friends: Enter Agentic Offensive Frameworks. 30 October 2026. https://cloud.google.com/blog/topics/threat-intelligence/artex-and-friends-enter-agentic-offensive-frameworks. Incident response and telemetry observations of ARTEX and PentAGI, the seven-stage model, and Mandiant's five layers of defense.
Google Threat Intelligence Group. GTIG AI Threat Tracker: From Prompting to Autonomy, The Evolution of Adversarial AI. 8 September 2026. https://cloud.google.com/blog/topics/threat-intelligence/from-prompting-to-autonomy-the-evolution-of-adversarial-ai. Q2 2026 trends, including the bespoke multi-agent credential harvesting campaign.
Microsoft Security Research and Microsoft Threat Intelligence. AI-driven, large-scale nation-state campaign using ARTEX enables supply chain compromise. 21 October 2026. https://www.microsoft.com/en-us/security/blog/2026/10/21/storm-0940-uses-artex-agentic-ai-connectwise-supply-chain-compromise/. Actor profile, timings, tenant counts, detections and hunting queries.
CrowdStrike Counter Adversary Operations. Unknown Threat Actor Uses AI-Driven ARTEX to Target South Korean Finance. 7 October 2026. https://www.crowdstrike.com/en-us/blog/unknown-threat-actor-uses-artex-to-target-south-korean-finance/. Infrastructure analysis and indicators for the campaign against South Korean financial organizations.
ConnectWise. Trust Center advisories: Cloud Backup service interruption. First published 16 October 2026. https://www.connectwise.com/company/trust/advisories. The vendor's own account of unauthorized access to application credentials.
MITRE ATT&CK. Technique pages for Kerberoasting (T1558.003) and DCSync (T1003.006), with detection strategies. https://attack.mitre.org/techniques/T1558/003/ and https://attack.mitre.org/techniques/T1003/006/.
Talk to Stingrai
Want to know how far one stolen credential gets in your environment, and how many minutes your team needs to stop it? Stingrai scopes assumed breach, Active Directory, cloud and purple team engagements with a retest, as a one-time annual engagement or a continuous program. Get a quote.
