Site Menu

Other Sites

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


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

Previous:

PHP2Shell emergency fixes: confirmed risks and the global rollout


AI disclosure: This article was prepared with AI assistance and reviewed against the linked PHP and vendor advisories. Status is as of October 22, 2026, 9:30 a.m. Central.

The PHP project released emergency fixes on October 21 for CVE-2026-109618 and CVE-2026-109619. Each is rated Critical, 9.2 under CVSS v4.0. Both can lead to unauthenticated remote code execution in affected PHP web runtimes. The first fixed upstream releases are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. PHP urges immediate updating and says configuration changes are not complete substitutes. [1]

The response is now a worldwide rollout across operating-system packages, cloud runtimes, hosting platforms, and web application firewalls. There is no reliable public count of sites that have finished patching. Amazon reports exploit attempts against its sensors as early as October 17, before public disclosure, and says attempts broadened after the fixes appeared. Its report does not establish how many real systems were compromised. [2]

The two vulnerabilities

CVE-2026-109618 — out-of-memory corruption. An allocation failure can interrupt PHP while internal request data is only partly initialized. Cleanup may then use invalid data. PHP validated remote code execution over HTTP against Apache mod_php with ordinary input and memory limits. PHP also considers PHP-FPM susceptible through paths reached after startup, although its advisory says a complete FPM exploit for this CVE had not been demonstrated. [3]

CVE-2026-109619 — stale global state. Data owned by one request can remain referenced after its memory is freed. A later request on the same worker may use the stale reference. PHP describes confirmed paths involving early configuration diagnostics and session upload progress, including a validated PHP-FPM path that depends on a suitable application operation. [4]

PHP says all installations serving web requests need assessment, including PHP-FPM, mod_php, php-cgi, FrankenPHP, and LiteSpeed. It places the highest demonstrated risk on mod_php, where an unauthenticated request can trigger an attack before application code runs. That distinction affects triage; it does not make other server arrangements safe to leave unpatched. [1]

Successful code execution runs with the PHP worker’s permissions. The data and systems at risk depend on what that worker can access. A WordPress, Drupal, or other application update alone does not repair the vulnerable PHP runtime. [1] [5]

How the updates are being applied worldwide

  • Linux distributions: Debian published a fixed PHP 8.4 package for Debian 13. Ubuntu published fixes for supported releases and extended-maintenance packages for older releases. Package version numbers may remain lower than PHP’s upstream fixed versions because the fixes are backported. Verify the distribution advisory and package revision, not a php -v number alone. [6] [7] [8]
  • Cloud platforms: Google Cloud says supported App Engine Standard runtimes receive automatic updates. Custom images, App Engine Flexible deployments, and Cloud Run or functions without automatic base-image updates require rebuilding or redeployment. AWS reports an updated Elastic Beanstalk PHP platform; customer-managed PHP instances and images require separate action. A provider platform update does not necessarily update PHP inside a customer-managed workload. [9] [10]
  • Hosting panels and providers: cPanel lists patched cPanel/WHM and EasyApache releases, including builds for some older PHP branches. Check the exact product and PHP package in use, and confirm serving workers were restarted. A shared-hosting announcement does not prove a separately managed VPS or custom container was updated. [11]
  • Edge defenses: Cloudflare says it enabled default WAF protections before public disclosure and observed attackers changing payloads. These controls add protection, but Cloudflare still directs customers to patch PHP. Confirm the ruleset is active and traffic cannot bypass the protected edge. [5]

PHP 8.1 and older receive no ordinary upstream release. PHP supplied minimal source backports for 7.4, 8.0, and 8.1, and some distribution and long-term-support vendors maintain fixes for older branches. Check the vendor’s exact package status; otherwise move to a supported, fixed branch. [1]

Exploitation and investigation

Amazon’s honeypot telemetry places a suspected exploit attempt on October 17 and further attempts before and after the October 21 release. Cloudflare also reports attack traffic against customers. These are reports of attempted exploitation, not a verified global tally of successful intrusions. For an internet-facing system that remained vulnerable, investigate activity from at least October 17 where logs are available. Review unusual web requests, PHP worker crashes, unexpected processes or file changes, and suspicious upload activity; preserve evidence before rebuilding a host suspected of compromise. Amazon cautions that observed IP addresses include shared anonymization infrastructure and should be investigated in context rather than treated as proof of compromise on their own. [2] [5]

Action plan for operators

  1. Find every PHP web runtime: public sites, internal applications, containers, managed hosting, appliances, background workers, and staging systems reachable by untrusted users. Record the installed package, update provider, web-serving PHP version, and service owner.
  2. Patch exposed systems first: install 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 or the vendor-confirmed backported package. Rebuild custom images and redeploy every affected instance.
  3. Restart and verify: restart PHP-FPM, Apache, or other PHP-serving workers as appropriate. Confirm the fixed package is installed and loaded by the process handling web requests. Ubuntu notes that automatic package installation may still require an application restart or reboot. [8]
  4. Handle systems awaiting a fix: reduce exposure or isolate them, and follow PHP’s specific temporary measures only after checking application impact. Those measures address particular attack paths and do not fully mitigate either vulnerability. The UK NCSC advises considering taking systems offline when immediate remediation is not feasible. [1] [12]
  5. Check for compromise and record exceptions: review available telemetry back to October 17 for exposed systems; document the deployed fix, worker restart, validation result, and any remaining unpatched service.

Current assessment: This has moved beyond a planned release to an active patching and investigation event. The fixed PHP versions are available, major distributors and providers have begun deploying them, and exploit attempts have been observed. Because each hosting and cloud model updates PHP differently, the decisive evidence is the fixed runtime actually serving each application, backed by its vendor advisory and a completed restart or redeployment.

Sources

Previous: Next: