Threat

ARTEX in the Wild: Storm-0940 Expands Targeting of IT and Software Vendors

Page published · Page updated

Dossier

Publication date unknown · First observed: 10 Nov 2026

Coverage timeline

discovered wiz.io primary 10 Nov 2026google.comobserved

Single-source incident — one report is available.

Why it matters

Adversarial use of agentic pentesting frameworks accelerates exploitation and lateral movement, increasing the importance of short-lived credentials, control-plane isolation, segmentation and behavioral detection.

GTIG and Mandiant report real-world intrusions using agentic pentesting frameworks including ARTEX, Hexstrike, CAIRN and PentAGI, with observed activity spanning lateral movement, database exploitation and exfiltration preparation. Supporting Wiz research describes ARTEX-associated targeting of IT and software vendors, overlapping Storm-0940 activity and focusing on identity systems and Microsoft 365 integrations.

campaign

Summary

Wiz observed an ARTEX-associated campaign targeting multiple IT and software vendors throughout October 2026. The activity concentrated on identity providers—including Okta, Entra, and Cognito—and Microsoft 365 integrations, with repeated attempts to identify authentication bypasses, enumerate APIs, and access vendors' customer data. Wiz reports overlap with Storm-0940, described as Chinese-state aligned; GTIG tracks an overlapping campaign as UNC7228. These relationships support a named-actor campaign assessment, but do not make ARTEX itself an actor-specific attribution marker.[0][1]

The observed playbook began with application mapping through client-side bundles, source maps, configurations, and API documentation, followed by authentication probing, password spraying, and account-recovery abuse. Wiz's supplied excerpt documents repeated attempts rather than demonstrating that every tested bypass or recovery mechanism succeeded. Separately, GTIG reports that the campaign extends back to at least August 2026 and includes compromise and data theft across enterprise software, industrial automation, semiconductor manufacturing and design, and telecommunications organizations in the United States and Europe.[0][1]

Speed is a central operational concern. GTIG reports that this campaign typically progressed from the first compromised account to deep system access in around four hours, with one case taking 15 minutes. The actor also adapted tooling to victim-specific environments and switched to open proxies when initial infrastructure was blocked. Across other ARTEX investigations, GTIG observed compressed execution bursts, iterative error correction, and abuse of legitimate administrative capabilities—evidence of accelerated attack execution, not proof that every intrusion was fully autonomous.[0]

Defenders should prioritize limiting what a compromised identity can reach and correlating authentication, management API, application, storage, and egress activity. The supplied Wiz excerpt does not enumerate campaign-specific malicious infrastructure or a vulnerable product/version pair. The hunting indicators below instead come from GTIG's broader, multi-actor ARTEX investigations and must not be treated as Storm-0940-specific attribution evidence.[0][1]

Attack chain

  1. 1. Map the application: Wiz observed the actor downloading JavaScript bundles, exposed source maps, runtime configurations, and Swagger/OpenAPI documentation to discover internal API routes and application functionality.[1]
  2. 2. Probe authentication behavior: The actor repeatedly initiated sign-in flows, manipulated OAuth callbacks and state parameters, tested unsigned JWTs, and probed SSO and Microsoft 365-specific endpoints. These are reported tests and attempts, not confirmed successful bypasses in every environment.[1]
  3. 3. Attack identity providers and login flows: The next reported playbook stage included password spraying against corporate Okta and Entra ID environments and targeting internal or proprietary application login pages.[1]
  4. 4. Abuse account-recovery functions: Wiz observed repeated invocation of password-reset, username-recovery, activation, and reset-token endpoints. The supplied excerpt ends during the playbook description, so no additional campaign stages are reconstructed from it.[1]

Disclosure timeline

DateEvent
July 2026According to Wiz, ARTEX was published on GitHub as an open-source autonomous penetration-testing framework.[1]
At least August 2026GTIG reports that expanded Wiz research dates the overlapping UNC7228/Storm-0940-associated campaign back to at least this month.[0]
October 8, 2026Wiz reports that ARTEX's developer made the tool closed-source after it had accumulated more than 12,000 forks. GTIG separately reports that the original repository was taken down during October because of widespread threat-actor abuse.[0][1]
Throughout October 2026Wiz identified ARTEX-associated targeting of multiple IT and software vendors, emphasizing identity systems, Microsoft 365 integrations, and attempted access to customer data.[1]
October 30, 2026GTIG and Mandiant published their broader assessment of ARTEX and other agentic offensive frameworks, including expanded campaign scope, incident-response observations, and defensive recommendations.[0]

Actor profile

Storm-0940

Wiz describes Storm-0940 as Chinese-state aligned and reports overlap between its observed ARTEX-associated activity and Microsoft's reporting on the actor. GTIG tracks an overlapping campaign as UNC7228. Reported targeting extends beyond IT vendors into enterprise software, industrial automation, semiconductor manufacturing and design, and telecommunications in the United States and Europe, with compromise and data theft observed. GTIG also reports rapid access expansion, victim-specific tooling changes, and fallback to open proxies. Attribution remains scoped to the overlapping campaign: ARTEX is used by multiple espionage and financially motivated actors, so its presence alone does not establish Storm-0940 involvement.[0][1]

How it works

The campaign's authentication testing targeted application and identity-flow behavior rather than a single disclosed vulnerability. Wiz observed manipulation of OAuth callbacks and state parameters, unsigned JWT tests, and probing of SSO and Microsoft 365-specific endpoints. Application bundles, source maps, runtime configurations, and API documentation supplied information about routes and functionality used during this testing. The excerpt does not identify a successful bypass condition or a corresponding CVE.[1]

A concrete exploitation mechanism appears in GTIG's broader ARTEX investigations, not as a demonstrated step of the Storm-0940-associated campaign. With supplied credentials, ARTEX accessed an application-specific SQL API on an external-facing Linux Weaver OA server. It attempted to cross from database access to operating-system execution by changing MySQL's general-log destination to a publicly accessible .jsp file, enabling general logging, and issuing SELECT statements containing Java code so that the code would be written into the log. The Java servlet could then parse and compile the JSP when accessed.[0]

That database-to-webshell attempt was iterative and noisy. GTIG observed successive JSP candidates and compilation errors, followed by revised webshells that returned valid command output. One investigation generated 240 log events, with errors potentially caused by multiple sub-agents overwriting one another. The example demonstrates how valid application access, excessive database privileges, writable web-accessible locations, and rapid feedback-driven retries can combine into execution without establishing a common product vulnerability across the campaign.[0]

Indicators of Compromise

TypeIndicatorContext
domainwebhook.siteGTIG observed broader ARTEX activity using 491 rotating endpoints on this service to retrieve scripts and return command results from an internal Windows database server, and also described command-output transfer to rotating endpoints. This is a shared legitimate service, not a campaign-exclusive malicious domain. Hunt unexpected production-server interactions in conjunction with process, identity, and transfer activity; the evidence does not attribute these observations specifically to Storm-0940.[0]
otherartex-probe-*Observed filename pattern from ARTEX access probing in GTIG investigations. The wildcard represents five-digit, somewhat-incremental suffixes, and files used different extensions. This is an observed intrusion artifact pattern, not a supplied full path or a Storm-0940-specific indicator.[0]
otherArtexProbeGTIG reports this marker in the naming convention associated with accounts and plaintext passwords created during ARTEX persistence activity. Search relevant account-creation and credential-management records in context; this broader ARTEX artifact does not independently establish actor attribution.[0]

Key takeaways

  • The campaign targets vendor identity and integration surfaces, not just vendor infrastructure: Wiz observed repeated testing of authentication, Microsoft 365 endpoints, and account-recovery functions across multiple environments.[1]
  • The strongest campaign-specific urgency is the reported access-expansion speed—typically around four hours and once 15 minutes. Controls that limit the reach of a compromised identity are therefore as important as detection.[0]
  • ARTEX is a shared capability, not an attribution signature. Keep the Storm-0940/UNC7228 overlap separate from GTIG's broader observations involving financially motivated and other suspected espionage actors.[0][1]
  • Current agentic intrusion activity can be both noisy and successful. GTIG's observations support rapid, feedback-driven automation across attack stages, while fully autonomous and stealthier operations remain a forecast rather than an established property of this campaign.[0]
  • The evidence favors behavioral and permission-focused defense over a single patch or static indicator set: legitimate credentials, supported management APIs, database capabilities, and application functions can supply the attack path.[0]

Defensive actions

  • Restrict application administration, publishing, and cloud management interfaces to trusted administrative paths.: GTIG observed ARTEX abusing Kudu administrative APIs for command execution and staging. Mandiant recommends separate Kudu/SCM access restrictions, limiting publishing credentials, and disabling basic publishing authentication when unnecessary. Reducing reachable administrative functionality limits the capabilities that automated tooling can test after obtaining credentials.[0]
  • Replace long-lived programmatic secrets with short-lived, workload-bound credentials and narrowly scope their permissions and authentication context.: ARTEX was observed rapidly testing obtained Azure and AWS credentials and their effective permissions. Mandiant recommends managed or federated identities, constrained resource access, and restrictions on where identities can authenticate so that a stolen credential does not immediately unlock unrelated systems or bulk data access.[0]
  • Continuously scan application configurations, repositories, build artifacts, pipelines, and databases for exposed credentials, and rotate exposed secrets promptly.: GTIG describes automated attack paths that connect compromised applications to cloud storage, source repositories, identity systems, and internal infrastructure through discovered credentials. Its guidance explicitly recommends removing embedded secrets and rotating them rather than relying only on source-history cleanup.[0]
  • Instrument and protect account-recovery and account-lifecycle operations, including high-risk password resets and bursts of account creation or permission changes.: Wiz observed repeated password-reset, username-recovery, activation, and reset-token requests. Mandiant recommends strong re-authentication or additional identity verification for high-risk recovery and monitoring for unusual lifecycle activity, directly addressing the campaign's recovery-focused testing.[0][1]
  • Remove database privileges that permit unnecessary server-wide configuration changes, arbitrary file writes, or operating-system execution.: GTIG's ARTEX example attempted to convert MySQL general logging into publicly accessible JSP webshells through an application SQL API. Restricting application database accounts from modifying server-wide settings or writing arbitrary files directly addresses that database-to-OS execution path.[0]
  • Segment internet-facing applications from identity infrastructure, management systems, and unrelated internal services.: Broader ARTEX investigations included internal enumeration and attempted movement toward domain controllers. Mandiant recommends allowing exposed workloads only the backend and authentication connections required for their function, reducing opportunities to chain application access into internal infrastructure compromise.[0]
  • Apply rate limits, recipient limits, transaction thresholds, and abuse controls to high-impact business APIs.: GTIG observed ARTEX weaponizing legitimate application functionality, including a notification system that sent test emails to more than 1,300 internal users. Limits on messaging, account creation, credential retrieval, and sensitive-data functions constrain this form of rapid feature abuse.[0]
  • Correlate authentication-origin changes with rapid permission checks, resource enumeration, data access, and new outbound destinations.: ARTEX activity can consist of individually legitimate operations performed in abnormal combinations and compressed bursts. Mandiant recommends sequence-based detection across identity, control-plane, data-plane, endpoint, and network telemetry, rather than relying solely on tool names, hashes, or IP addresses.[0]
  • Investigate unexpected webhook-service traffic from production servers and preserve the process and network context needed to explain it.: GTIG observed ARTEX using rotating webhook.site endpoints for command-and-control and command-output transfer. Mandiant recommends controlling server egress and monitoring previously unseen webhook, tunneling, file-transfer, and external AI destinations. Google SecOps also provides the named detections Suspicious Webhook.Site Interaction, Suspicious Curl Invocation, Cmd Launching Curl, and AWS Cloud Accounts Getcalleridentity.[0]