An ARTEX agent generated 27 AWS-permission events in 23 seconds during an intrusion investigated by Google Threat Intelligence Group and Mandiant. Their October 30 research describes attackers putting compromised credentials into agentic offensive frameworks, then letting the software test access, adjust to failures and continue into cloud and application systems. Organizations whose identities can reach administrative APIs, cloud resources and internal web applications face a much shorter interval between stolen access and deeper intrusion.
Since late August, the researchers have seen threat actors use ARTEX, PentAGI, CAIRN and other offensive frameworks during incident-response engagements. ARTEX activity included post-compromise reconnaissance, lateral movement, privilege escalation and preparation for data theft. In one application case, ARTEX generated 240 log events while working through an exposed API. Human attackers still choose targets and objectives; the framework handles many of the intervening attempts.
Credentials Feed Rapid Permission Tests
ARTEX is a multi-agent offensive framework that turns a high-level goal into tool-driven tasks. In several investigated intrusions, attackers supplied it with credentials already compromised at the target organization. The agent then explored what those identities could reach. The Google team writes that it found “27 events in 23 seconds of active burst time” while ARTEX probed AWS permissions across security groups. That count is events, from one observed burst, rather than accounts or separate victims. The observed intrusions also included extended operational pauses between fast execution sequences.
Other observations show how the probing crosses environments. ARTEX checked Azure credential capabilities, including a test blob write followed immediately by deletion in roughly 330–400 milliseconds. It used cloud-management dry runs and tested compute permissions. A credential with broad reach gives automated tooling many possible next steps; one scoped identity and a restricted administrative route give it fewer.
The report also describes attempted cloud privilege escalation through instances assigned valuable IAM roles. Those particular attempts apparently failed because the instance-profile ARNs were invalid. Check for a successful role change before treating those rapid permission tests as privilege escalation. The team characterizes current use as often noisy, sometimes successful, and still at an early stage.
Web API Errors Expose Iteration
In a separate case, valid credentials let ARTEX access an internet-facing Linux Weaver OA web server through application-specific APIs. ARTEX used an available SQL interface while seeking system-level execution. The observed sequence involved changes to MySQL logging settings, writes toward web-accessible .jsp files, repeated errors and fresh webshell candidates. The researchers recorded 240 log events around the attempt; some errors may have come from sub-agents interfering with one another. The names cl1217.jsp, f1219a.jsp and z1219.jsp identify observed webshell candidates, while general_log_file and general_log are useful database-setting tokens to investigate in that application context.
In another access-probing case, generated files carried the prefix artex-probe- and a five-digit suffix. The researchers also saw ArtexProbe in created-account naming. Those strings are leads for a targeted investigation, rather than a complete detector: the framework can use other filenames, and the same behavior can occur without its name in a log. Review which identity made each request, where it came from, what failed, and what succeeded next.
ARTEX used legitimate functionality as well as attempted webshells. In one investigated application it triggered notification emails to more than 1,300 internal users, then switched to single-recipient tests. The count is internal email recipients in that incident, not a count of compromised accounts. The application notification trail belongs beside identity and administrative logs when reconstructing access.
Separate the Publishing Door
For Azure App Service environments, one useful access change is to restrict the Kudu/SCM advanced-tools site separately from the public application. Google describes attackers abusing Kudu administrative APIs to execute commands and stage scripts. Microsoft’s access-restriction documentation says the main site and the SCM site each have a rules collection; the SCM site can instead use the main site’s rules. Review the SCM rules and unmatched-rule action for each affected app. Permit only the deployment network or approved administrative path, and verify that a request from an unapproved public path is denied while the legitimate deployment path still works. A public application can remain available while its deployment interface is restricted.
Apply the same access logic to the credentials driving the cloud side of the incident. Replace long-lived workload secrets where feasible with short-lived credentials, reduce service-principal and IAM permissions to what the workload needs, and restrict who can reach administration and publishing endpoints. These changes constrain what a supplied credential can do even if the attacker can still prompt a framework to test it. Mandiant also recommends segmenting application tiers and monitoring management APIs, identities and storage activity together.
Pair Identity Logs With Access Changes
Start with identities and services that can administer App Service, call cloud management APIs, access storage or reach application SQL interfaces. Correlate their sign-ins with clusters of permission tests, failed operations and subsequent changes to keys, instances, accounts or database settings. In the relevant web application, search for artex-probe-, ArtexProbe, the observed .jsp filenames and changes to general_log_file or general_log; interpret those tokens against the actual application and database logs. Examine application notification logs if that feature was reachable. One 27-event AWS burst and a separate 240-event web-API sequence describe different investigated activity, so correlate each within its own identity and timeline.
Restrict the SCM management route, shorten the lifetime of exposed credentials and reduce their permissions. Test the SCM access rule from an allowed deployment path and from an unapproved external path; the expected result is a working approved deployment and a denied external management request. Then investigate earlier identity and host activity separately: a newly denied route blocks one access path, while the logs and credential rotation address access already obtained.