Hackers Use ARTEX AI to Automate Enterprise Attacks at Machine Speed – Insights for Defenders

AI-powered offensive frameworks are helping attackers move from stolen credentials to cloud privilege escalation, lateral movement, and data theft in minutes. Recent ARTEX campaigns show why organizations must rethink how they detect and stop automated intrusions.

Cybercriminals and state-linked hacking groups are increasingly using an artificial intelligence-powered framework called ARTEX to automate complex attacks against enterprise networks, cloud platforms, and identity systems.

Unlike traditional attack tools that require operators to manually select and execute each step, ARTEX uses multiple AI agents to investigate targets, run security tools, interpret results, and determine what to do next.

The framework has already appeared in real-world intrusions involving government agencies, financial institutions, technology companies, and critical industries.

Research published by Google Threat Intelligence Group and Mandiant on October 30, 2026, identified ARTEX being used for Active Directory attacks, privilege escalation, cloud infrastructure reconnaissance, lateral movement, and preparation for data exfiltration.

Microsoft separately linked ARTEX to Storm-0940, a China-state-aligned threat actor that used the framework to accelerate attacks involving compromised ConnectWise application credentials and Microsoft 365 environments.

In another campaign, CrowdStrike identified the China-nexus group VAPOR PANDA using ARTEX to target more than 200 organizations worldwide.

These investigations show a significant change in offensive operations. Attackers are no longer limited to using AI to generate scripts or explain vulnerabilities. They are increasingly connecting AI models directly to tools capable of performing actions inside targeted environments.

For defenders, the biggest concern is not necessarily a new exploitation technique. It is how quickly existing weaknesses can be discovered, combined, and abused.

What Is ARTEX AI?

ARTEX is an AI-powered penetration-testing and offensive security framework designed to automate different stages of a security assessment.

Originally released publicly on GitHub in July 2026, it was developed as a multi-agent system capable of coordinating reconnaissance, vulnerability assessment, exploitation, and post-compromise activities.

The framework is written in Go and includes a web-based management interface built with Next.js. Its architecture combines large language models (LLMs) with specialized agents responsible for planning and carrying out tasks.

Rather than acting as a simple chatbot, ARTEX can use available tools, examine their output, and adjust subsequent actions based on what it discovers.

A typical workflow involves an operator defining a target and objective. The system then divides that objective into smaller tasks, delegates them to specialized agents, and records discovered assets, credentials, vulnerabilities, and other findings in a shared graph.

This shared information allows agents to build on previous discoveries instead of repeatedly starting from scratch. According to Google, the framework supports six specialized sub-agents and can work with different AI models.

The original repository was taken down by its creator in October 2026 following reports of malicious use. However, copies and modified versions continue circulating through community forks and commercial variations.

ARTEX itself is a dual-use security framework, not a vulnerability or a malware family. Authorized penetration testers can use similar automation to assess security weaknesses. The danger emerges when threat actors direct these capabilities against organizations without permission.

ARTEX Automate Enterprise Attacks

A conventional enterprise intrusion often requires a human attacker to spend considerable time investigating the environment.

The attacker must identify available systems, understand access permissions, test credentials, examine errors, and determine which weaknesses can lead to additional privileges. Some of these activities require different skills or specialized tools. ARTEX can automate substantial portions of that process.

For example, after obtaining access to a compromised application or cloud account, an agent may examine available permissions and identify accessible services.

It may then test whether those permissions allow access to additional infrastructure, data repositories, or administrative functions. If one approach fails, the framework can analyze the response and attempt an alternative.

Google’s investigation found individual ARTEX execution bursts lasting approximately 2 to 25 seconds. In one observed operation, the framework generated 27 events in 23 seconds while testing AWS permissions.

These measurements describe individual sequences of automated activity, not the total time needed to compromise an organization. The distinction matters because the overall intrusion may still involve pauses, failed attempts, or human intervention.

Nevertheless, even a short burst can be enough to enumerate permissions, modify cloud resources, or trigger additional attack steps before an analyst investigates the first alert.

ARTEX also creates a different operational challenge. Multiple agents can work through separate tasks, producing large amounts of activity across different security systems.

An attack that initially appears to be ordinary scanning can rapidly progress into credential abuse, privileged access, and data collection.

The underlying security failures are familiar. These include stolen passwords, excessive permissions, vulnerable applications, poorly protected administrative interfaces, and exposed credentials.

What ARTEX changes is the speed at which these weaknesses can be connected. A vulnerable public-facing application might expose a credential. That credential could provide access to a database or cloud storage account. Additional secrets discovered there might grant access to administrative systems.

An automated agent can investigate this chain with far less manual effort than a human operator. This is particularly dangerous in organizations where applications, cloud resources, and identity systems are highly interconnected. A weakness that appears limited to one workload can become the starting point for a much wider intrusion.

Real-World ARTEX Attacks Targeting Organizations

Security researchers have documented several campaigns involving ARTEX. These investigations matter because they show different ways the same framework can be misused.

Not all the reported activities belong to the same threat actor, and attempts to access systems should not be confused with confirmed compromises.

Storm-0940 Uses ARTEX in Microsoft 365 and ConnectWise Attacks

On October 21, 2026, Microsoft Threat Intelligence reported that Storm-0940 had been using ARTEX since at least September to automate attacks against organizations across multiple industries.

The campaign included aerospace, defense, energy, financial services, government, manufacturing, and technology organizations. In several ARTEX-driven intrusions, Microsoft observed the attackers obtain privileged cloud access in less than three hours after initial targeting.

One especially significant incident involved unauthorized access to application credentials associated with ConnectWise Cloud Backup, formerly known as SkyKick.

These applications had already been authorized to operate in customer Microsoft 365 environments. After obtaining control of affected application identities, the attackers attempted to authenticate to more than 2,250 Microsoft 365 tenants.

Rather than requiring an employee to enter a password, the attackers abused existing application trust and permissions. This allowed application-only authentication without the normal interactive sign-in process.

In some environments, Microsoft observed follow-on Microsoft Graph activity involving cloud reconnaissance, application credential modifications, and attempts to change privileged access.

Such changes can be especially dangerous because newly added credentials or permissions may survive even after the initially compromised application is disabled.

Microsoft also documented a related password-spraying operation between October 10 and 14. During that activity, infrastructure associated with Storm-0940 generated more than 151,000 failed authentication events while targeting 327 accounts across eight organizations.

The activity peaked at approximately 2,900 failed attempts per minute. Microsoft did not observe successful authentication in that specific password-spraying dataset. The separate ConnectWise application-credential activity did result in unauthorized sign-ins and additional actions in some environments.

The 2,250-tenant figure represents attempted access, not 2,250 confirmed breaches. Successful application authentication also does not, by itself, prove that customer information was stolen.

The incident demonstrates the risk of granting extensive permissions to trusted third-party applications. Once those application credentials are compromised, attackers may be able to reuse existing access without exploiting a vulnerability in the cloud provider itself.

ARTEX Targets Enterprise Identity Providers and Software Vendors

Researchers at Wiz identified ARTEX-associated attacks against software and IT companies during October 2026. The activity overlapped with the campaign Microsoft tracks as Storm-0940.

Investigators observed attempts to map web applications, enumerate exposed API functionality, probe authentication mechanisms, and access resources belonging to other customers.

The attacks involved identity platforms including Microsoft Entra ID, Okta, and Amazon Cognito. In several cases, the agent examined publicly accessible JavaScript files, configuration resources, and API documentation to learn how an application operated.

It then attempted to interact with authentication endpoints, password-recovery features, and application functions.

Wiz observed password-spraying activity occurring in coordinated bursts, with a median gap of approximately one second between attempts.

Some bursts continued for 20 to 60 minutes. Other activity lasted much longer. Researchers documented sessions extending for 24 to 30 hours.

When an IP address was blocked, subsequent activity sometimes appeared from another address within minutes. The attackers also varied user-agent strings and repeatedly tested different endpoints. Importantly, most observed attempts were unsuccessful.

However, the automation shows why a single blocked request or a temporary rate limit is not always enough to stop an attacker who can continually test alternative paths.

VAPOR PANDA Uses ARTEX to Target More Than 200 Organizations

A separate investigation published by CrowdStrike on October 29, 2026 documented ARTEX use by VAPOR PANDA, a China-nexus espionage group.

This operation was distinct from the Storm-0940 campaign. Beginning October 17, the attackers used ARTEX against more than 200 organizations across government, telecommunications, defense, semiconductor, pharmaceutical, and other industries.

The targeting extended across at least 14 countries during an 11-day period. CrowdStrike confirmed post-exploitation activity at nine organizations.

The attackers used ARTEX for multiple concurrent intrusions, with a human operator providing directions while AI agents performed tasks. The group combined ARTEX with DeepSeek and another commercial AI model.

Its activities included investigating cloud configurations, exploiting weaknesses in applications, gathering credentials, and moving through compromised environments.

CrowdStrike also observed the deployment of the BLOODALCHEMY backdoor, which supported continued malicious access. In some operations, attackers instructed the agents to identify Windows systems without endpoint security coverage.

This finding highlights another risk: automated attackers can potentially use information about defensive coverage to select less-protected systems.

The VAPOR PANDA case demonstrates that ARTEX is not restricted to opportunistic scanning. It can also support targeted espionage operations directed by experienced attackers.

What ARTEX Can Do After Initial Access

Google’s investigation provides some of the clearest examples of how ARTEX behaves after attackers gain a foothold.In multiple incidents, the attackers provided the framework with already-compromised credentials. ARTEX then performed additional reconnaissance and attempted to expand access.

Active Directory Reconnaissance and Privilege Escalation

Google observed ARTEX running automated PowerShell reconnaissance against Windows domain infrastructure. The activity included identifying accounts, examining managed service accounts, reviewing Active Directory Certificate Services configurations, and mapping relationships across trusted domains.

Some operations used Kerberoasting techniques to obtain service tickets associated with domain accounts. Kerberoasting is a technique that can expose service account passwords when weak credentials are used.

Researchers also observed DCSync activity aimed at obtaining sensitive domain authentication material. Successful abuse of domain replication privileges can expose credentials needed to compromise additional accounts and systems.

ARTEX attempted lateral movement through techniques involving existing authentication material and Windows remote administration capabilities.

In one case, endpoint defenses blocked part of the activity before defenders disconnected the affected server. The findings demonstrate why protecting domain controllers, service accounts, and privileged credentials remains important even when the attack is AI-assisted.

Further technical details are covered in our report on ARTEX-assisted Active Directory attacks and lateral movement.

Cloud Permission Discovery and Credential Abuse

ARTEX has also been observed investigating Azure and AWS environments. Instead of assuming that a discovered credential has administrative access, the framework can test what actions the identity is permitted to perform.

This can include identifying accessible cloud resources, examining storage permissions, and evaluating management capabilities.

Google observed rapid permission checks and short sequences of cloud resource operations. Such behavior can help an attacker determine which credentials are useful for moving deeper into an environment.

Overly privileged service principals, static cloud access keys, and unrestricted workload identities can therefore become attractive targets.

Exploiting Legitimate Application Features

Another concerning finding is that ARTEX does not always need to deploy a traditional malware payload to cause harm. Google documented activity involving legitimate application functions being used in unintended ways.

In one incident, the framework attempted to cross from database access into operating-system execution. The process generated approximately 240 log events as the agents repeatedly adjusted their approach.

In another case, the framework abused an application’s notification capabilities to trigger messages to more than 1,300 internal users.

This demonstrates that legitimate features can become useful attack tools when access controls are weak or application permissions are excessive. A practical defense strategy begins with understanding where automated activity leaves evidence.

The following table summarizes observed behaviors and the logs defenders should prioritize.

Attack phase	Suspicious activity	Useful detection sources
Reconnaissance	Rapid requests for configuration files, API documentation, and unusual application paths	WAF, reverse proxy, HTTP access logs
Credential attacks	Password-spraying bursts, repeated authentication failures, account recovery abuse	Entra ID, Okta, Cognito authentication logs
Initial access	Unusual successful sign-ins by user accounts or service principals	Identity sign-in logs, cloud audit logs
Privilege escalation	New application credentials, privileged role assignments, abnormal permission changes	Entra audit logs, Microsoft Graph activity, IAM logs
Lateral movement	Unexpected remote administration, authentication, or directory enumeration between systems	EDR, Windows security logs, network telemetry
Data collection	Unusual mailbox access, cloud storage enumeration, bulk secret retrieval	Microsoft 365 audit logs, Key Vault, storage audit logs
Persistence	New administrator accounts, credentials, application grants, or unexpected workload changes	Identity audit logs, cloud configuration monitoring

These behaviors are not exclusive to ARTEX. Legitimate scanners and administrative automation may produce similar events. The strongest detections depend on correlating multiple activities and comparing them against approved behavior.

How Defenders Can Detect ARTEX-Driven Attacks

1. Monitor Non-Human Identities and OAuth Applications

The ConnectWise incident showed that an attacker may not need to compromise a normal employee account. An application identity with broad permissions can provide access to valuable resources without interactive user authentication.

Organizations should maintain an inventory of service principals, OAuth applications, API credentials, and other workload identities. For each identity, security teams should understand its owner, permissions, normal authentication sources, and expected operations.

Defenders should investigate unfamiliar application sign-ins, especially when followed by credential additions, new permissions, or privileged directory changes.

Microsoft recommends using the OAuthAppInfo, EntraIdSpnSignInEvents, and GraphAPIAuditEvents tables in Defender XDR to investigate affected applications and their subsequent activity.

The Microsoft technical report provides ready-to-run hunting queries that can be adapted to an organization’s environment.

2. Detect High-Speed Sequences, Not Just Individual Events

Traditional detection rules frequently evaluate individual events. An authentication failure might be treated as low risk. A cloud resource listing might be normal. A configuration query may not trigger an alert.

However, those activities become more concerning when they appear together within seconds. For example, a suspicious sequence might involve an unfamiliar application authentication, immediate resource enumeration, a credential change, and access to sensitive storage.

The correlation between those events may reveal an intrusion that would otherwise be missed. Security teams should build detections around unusual event velocity, unexpected sequences, and changes in an identity’s established behavior.

Alerts involving access to privileged systems or sensitive data should receive higher priority.

3. Monitor Active Directory and Internal Movement

Organizations should watch for unusual directory enumeration, unexpected service ticket requests, and suspicious authentication activity involving privileged accounts.

Kerberoasting attempts may be visible through Windows security event 4769 when appropriate auditing is enabled. Potential DCSync activity can be investigated through directory replication-related events, including event 4662, where the required audit settings are configured.

Defenders should also monitor unusual WinRM, SMB, and remote service activity between systems that do not normally communicate. Pay particular attention to domain controllers, identity servers, certificate services, and administrative workstations.

4. Watch for Abnormal Cloud API Activity

Cloud environments generate valuable evidence of automated attacks. Security teams should monitor rapid permission testing, unusual resource enumeration, repeated authorization failures, and unexpected changes to IAM roles.

Additional high-value detections include bulk access to cloud secrets, sudden increases in storage reads, and management API calls from unfamiliar infrastructure.

Cloud access should be evaluated in context. A build server accessing a known storage bucket during deployment may be normal. The same identity suddenly accessing unrelated production secrets from an unfamiliar network should trigger investigation.

5. Look for Automation Artifacts Without Relying on Them Exclusively

Researchers have identified ARTEX-related artifacts such as artex-probe-* filenames and other distinctive naming patterns. CrowdStrike has also documented campaign-specific identifiers involving artx or artex strings.

These indicators can help investigators identify known activity. However, attackers can change filenames, infrastructure, and user-agent strings.

A defender who searches only for the ARTEX name may miss the actual attack. Behavior-based detection remains essential because malicious agents can carry out activities using ordinary administrative tools and legitimate credentials.

Indicators of Compromise Associated With Storm-0940

The following IP addresses were published in connection with the Microsoft 365 and ConnectWise campaign.

Indicator	Type	Investigation context
144.172.64[.]128	IPv4	Suspicious application authentication and related activity
144.172.64[.]99	IPv4	Password-spraying infrastructure and related campaign activity
144.172.64[.]60	IPv4	Additional infrastructure associated with suspicious sign-ins

Security teams investigating the ConnectWise incident should also identify the following legitimate application IDs.

Application	Application ID
ConnectWise Cloud Backup	506e08f9-6e9a-4da4-942b-a099a03644ae
ConnectWise Cloud Management – MS Teams	24205314-2b89-4e07-a2a4-579e898a5640
ConnectWise Cloud Management – MS Graph	0de14c77-b9b0-4137-9360-34878a929827

These application identifiers belong to legitimate integrations and are not malicious indicators by themselves. Organizations should consult the full vendor advisory for additional affected identities and investigation instructions.

Similarly, an IP address match or a common Python user-agent string should be treated as investigative evidence rather than automatic proof of compromise.

Incident Response Checklist for Suspected ARTEX Activity

Organizations investigating potential ARTEX or Storm-0940 activity should prioritize the following actions.

1. Determine exposure. Inventory affected applications, service principals, credentials, and systems. Review both current and previously authorized integrations.
2. Preserve evidence. Collect authentication records, cloud audit logs, application changes, endpoint telemetry, and relevant network activity before making irreversible changes.
3. Reconstruct the timeline. Correlate the first suspicious access with subsequent API calls, permission modifications, administrative activity, and data access.
4. Contain confirmed access. Disable compromised identities or connections, revoke unauthorized permissions, and rotate affected credentials through an approved incident response process.
5. Search for secondary persistence. Investigate new application secrets, administrator accounts, role assignments, mailbox changes, scheduled tasks, and other access paths the attacker may have created.
6. Validate recovery. Confirm that unauthorized access has ended, essential services are functioning, and enhanced monitoring remains in place.

For organizations affected by the ConnectWise incident, Microsoft recommends reviewing activity from at least October 15, 2026, and extending service-principal investigations to October 1 where logs are available.

According to ConnectWise’s October 30 advisory, restoration of Cloud Backup is underway through a new, security-hardened application. Backup and restore capabilities have resumed for re-authorized Microsoft 365 tenants.

Partners should follow ConnectWise’s official re-authorization instructions, verify that new backup snapshots are being created, and avoid re-enabling previously disabled application connections unless specifically instructed.

Re-authorizing an application does not replace the need to investigate possible unauthorized access or remove attacker-created credentials.

The post Hackers Use ARTEX AI to Automate Enterprise Attacks at Machine Speed – Insights for Defenders appeared first on Cyber Security News.