Site Menu

Other Sites

ARTEX in the Wild: Attacks and a Blue-Team Monitoring Guide

Posted on 20261028 by 0xF21D

AI disclosure: This article was prepared with AI assistance and checked against the linked primary research and vendor guidance. Reporting and ConnectWise status were reviewed October 28, 2026.

ARTEX is an AI-assisted penetration testing framework that legitimate teams can use within an authorized scope. Investigators have also found it in real intrusions. The defensive issue is the speed and scale with which an operator can combine familiar steps—reconnaissance, authentication attacks, privilege changes, and data access. There is no reliable single “ARTEX signature” for a defender to watch. The useful signals are the actions and their sequence. [1] [7]

What ARTEX does

ARTEX coordinates multiple large-language-model agents. An operator provides a target and objective; a planner selects tasks, workers run security tools, and results feed a shared graph of assets and findings. The framework can use different AI models, and published versions used a Go backend and Next.js interface. Its original public repository was later closed, but copies and forks remain. The tool’s existence does not by itself make an assessment malicious; authorization and the operator’s activity determine that. [1] [6]

ARTEX can accelerate an attacker’s existing techniques rather than create a new class of exploit. Researchers have observed it used alongside custom scripts and AI coding assistants. Network traffic may therefore resemble ordinary scanners, scripts, browsers, or cloud API clients, and may change during an operation. [5] [6]

Attacks and campaigns in the reporting

South Korean financial organizations, late September–early October 2026

CrowdStrike found an attacker-controlled ARTEX deployment, configuration files, and AI session histories tied to intrusions at South Korean financial organizations. Zscaler reports that the campaign exploited peripheral web applications, including inquiry portals and employee mobile backends, using techniques such as SQL injection and authentication bypass. Zscaler says personal data on approximately 67,000 people was exfiltrated. Its broader analysis found that the same operator’s records also described targets in other countries and sectors; those records do not establish that every listed target was breached. [3] [4] [5]

CrowdStrike did not assign this activity to a named group. CrowdStrike and Zscaler assess a financially motivated, Chinese-speaking operator with moderate confidence; language and tool origin are clues, not proof of nationality or government direction. This campaign should not be conflated with Microsoft’s Storm-0940 attribution below. [3] [4]

Storm-0940 and the ConnectWise Cloud Backup compromise, October 2026

Microsoft attributes a separate ARTEX-driven campaign to Storm-0940, which it assesses as China-state aligned. Microsoft says the actor used compromised ConnectWise application credentials and existing tenant trust to attempt sign-ins across more than 2,250 Microsoft 365 tenants. That figure is attempted tenant reach, not a count of compromised tenants. In some environments, activity progressed to Microsoft Graph and directory operations, added application credentials, and changed privileged roles; Microsoft reports multiple cases in which privileged cloud access followed initial targeting in less than three hours. [1]

Microsoft also recorded more than 151,000 failed sign-ins during an October 10–14 password spray against 327 accounts at eight organizations. It reported no successful sign-in or follow-on activity from that spray itself. The later abuse of stolen application credentials is a distinct part of the campaign. The public reporting does not establish how those ConnectWise credentials were acquired, so this should not be described as a confirmed product exploit. An affected application, a successful service-principal sign-in, and data exfiltration are three different findings that require separate evidence. [1] [2]

In its October 27 update, ConnectWise said it was awaiting third-party validation before phased partner restoration, and instructed partners to keep affected application connections disabled until service-specific guidance is issued. It reported no indication that stored backup archives were compromised, while stressing that individual Microsoft 365 tenants still need review. Check its Trust Center for any later change before acting on service status. [2]

Broader software-vendor targeting

Wiz reports ARTEX-associated activity against multiple IT and software vendors, overlapping with Microsoft’s reported Storm-0940 activity. Its logs show source-map and API-documentation downloads followed by requests to newly discovered endpoints; testing of OAuth/SSO callbacks, account recovery, and cross-tenant access; and password spraying against Okta and Entra ID. Wiz observed the actor also probing AWS Cognito. Most attempts it describes failed. The report supports an expanding targeting pattern, not a blanket claim that all targeted vendors were breached. [6]

How blue teams should monitor

Prioritize linked behavior over a product name, model-provider domain, fixed user agent, or one IP address. ARTEX can use different models and ordinary tools; its operators can change infrastructure and user agents. Huntress independently observed fast tooling changes in the ConnectWise incident but could not see the attackers’ systems or confirm ARTEX from its own telemetry alone. [7]

  1. Watch the exposed application path. Retain reverse-proxy, WAF, API-gateway, and application logs with request path, response, identity, source, user agent, and precise time. Alert on a short chain of source-map/configuration/OpenAPI retrieval, calls to internal routes found there, repeated OAuth or SSO variations, password-reset or username-enumeration bursts, and sequential record access. Include employee and partner portals, not only the main customer site. [6]
  2. Correlate identity events across systems and tenants. Detect failed attempts across many users in Entra, Okta, and Cognito, then any unexpected success or privileged action. Aggregate by source, account set, application, and time window across an MSP’s customer estate. A low volume in each tenant can be a large cross-tenant campaign. Source and user-agent rotation should increase scrutiny rather than break correlation. [6] [7]
  3. Inventory trusted applications and monitor app-only sign-ins. For the ConnectWise case, search application client IDs in every current or formerly connected tenant, record each tenant’s service-principal Object ID, and compare successful and failed service-principal sign-ins with the vendor’s normal source ranges and user agents. Consult both Microsoft’s hunting list and ConnectWise’s full application list; the lists have different scopes. Review from at least October 15 and extend back to October 1 where logs permit. [1] [2]
  4. Page immediately on cloud persistence or privilege changes. High-value alerts include a service principal adding a secret or certificate; a new owner, consent grant, or app-role assignment; an application assigning itself or a sibling principal Global Administrator or another high-privilege role; and changes to users, groups, authentication methods, or Conditional Access. These signals remain useful even when the attacker changes IPs. [1] [7]
  5. Trace access to data, not just authentication. Where available, enable and retain Microsoft Graph activity logs and correlate them with Entra audit, Microsoft 365/Purview audit, Key Vault, SharePoint, Exchange, and other workload records. Look for unusual API enumeration, secret reads, mailbox or file access, bulk downloads, forwarding rules, and outbound transfers. Missing Graph logs limit certainty: a successful sign-in alone neither proves nor rules out data access. [1] [7]
  6. Use campaign indicators as pivots. Microsoft lists 144.172.64[.]128, .99, and .60, plus programmatic user agents including Python-urllib/3.12 and curl/7.88.1. Huntress associates .128 with application sign-ins and .99 with the password spray in its telemetry. Hunt on these with the relevant date, app ID, and follow-on behavior; none is proof of compromise alone. [1] [7]

A practical first response

If the chain appears in your logs, preserve the raw identity, application, Graph, web, and workload records. Scope the full set of affected applications and tenants, then check for attacker-added credentials, owners, grants, roles, and new identities before deciding that access has ended. Have an authorized responder remove confirmed unauthorized persistence and rotate affected credentials. For the ConnectWise incident, follow the vendor’s current containment and reconnection guidance; disabling the original connection does not undo changes already made inside a tenant. [1] [2]

The strongest general defense is to detect the progression from discovery to identity abuse to privilege and data access quickly enough to interrupt it. Request cadence and AI-related network calls can help an investigation, but behavior and authorization changes carry the decision. [7] [6]

Sources

Posted under: Artificial Intelligence, Blueteam Defense, CyberSecurity
Previous:
Content ©2026 Robert Hollingshead unless otherwise indicated.