AI Helped Hackers Target 200 Organisations. Nine Were Breached

An AI-powered hacking framework helped a threat actor run attacks against more than 200 organisations across at least 14 countries. CrowdStrike confirmed post-exploitation activity at nine. A separate Dutch incident shows how quickly attackers can use the same framework after gaining access to a vulnerable system.

Hackers are increasingly using artificial intelligence to do more than write convincing phishing messages or generate malicious code. Some are now using AI-powered frameworks to coordinate multiple technical tasks during an intrusion, allowing them to investigate systems, test different routes and move through networks at a speed that would be difficult to match manually.

A campaign uncovered by cybersecurity company CrowdStrike shows how this approach is developing.

In a report published on 29 October 2026, CrowdStrike said a threat actor it tracks as VAPOR PANDA had used an AI-assisted framework called ARTEX to target more than 200 organisations worldwide. The activity began on 17 October and covered at least 14 countries.

However, the number of targets should not be confused with the number of confirmed compromises. CrowdStrike confirmed post-exploitation activity at nine organisations. It also observed password-spraying and credential-scanning activity against at least 12 additional organisations, but did not describe those cases as confirmed breaches.

The findings matter because they show how attackers can use AI agents to coordinate established hacking techniques across multiple targets. They also reveal an important limitation in the idea of autonomous hacking: in the CrowdStrike investigation, a human operator still gave instructions and guided the system at important points.

More than 200 organisations were targeted

CrowdStrike said VAPOR PANDA began using ARTEX against organisations on 17 October 2026. Its investigation identified activity across at least 14 countries during an 11-day period.

The targets included government departments, foreign ministries, telecommunications providers and organisations in sectors such as pharmaceuticals, semiconductors, defence, nuclear technology and finance.

One operation focused on 19 US-based organisations. Other activity involved foreign ministries in Latin America, Europe and Asia, as well as government and telecommunications organisations in other regions.

CrowdStrike confirmed post-exploitation activity at nine organisations. In those cases, the attacker gained access and carried out additional actions, including deploying a backdoor called BLOODALCHEMY, scanning networks, conducting reconnaissance and attempting to obtain further credentials.

At least 12 other organisations experienced password-spraying or credential-scanning activity.

These findings describe different levels of activity. Being targeted or scanned does not automatically mean an organisation was successfully breached. The nine confirmed cases are the organisations for which CrowdStrike reported post-exploitation activity.

What is ARTEX, and how does it help attackers?

ARTEX is an open-source, AI-driven framework designed to coordinate multiple agents during penetration-testing and offensive security tasks.

In ordinary terms, it can be thought of as a system that gives an AI model a technical objective and allows several specialised agents to work through parts of the task. One agent may investigate a system, another may examine possible routes into it, and others may help carry out follow-up actions.

The framework can connect to large language models (LLMs), which are AI systems capable of processing instructions and generating responses. These models help the agents interpret information, decide what to try next and produce commands or scripts.

That does not mean ARTEX independently discovers every weakness or successfully compromises every system. Its results still depend on the access, information, tools and instructions available to it, as well as the security weaknesses it encounters.

The important change is how the work can be coordinated. Instead of one operator manually performing every step, multiple agents can investigate different paths and attempt technical tasks in parallel.

Google’s Threat Intelligence Group and Mandiant have also documented threat actors using ARTEX and other agentic frameworks, including Hexstrike and CAIRN, in separate investigations. Their findings suggest that this is not limited to one campaign or one threat actor.

A human operator was still directing the operation

One of the most important details in CrowdStrike’s investigation is the role played by the human attacker.

VAPOR PANDA ran ARTEX primarily with DeepSeek, a large language model developed in China, alongside a second subscription-based commercial model that CrowdStrike could not identify.

Recovered ARTEX records showed a human operator issuing instructions in Chinese. The operator directed the agents at important decision points, including telling them to look for Windows machines that did not have CrowdStrike’s Falcon security sensor installed.

This matters because it gives a more accurate picture of how AI-assisted hacking is being used.

The framework automated parts of the technical work, but the investigation did not describe an operation in which AI independently made every decision without human involvement. The operator remained involved and steered the agents when necessary.

The distinction is important: AI can increase the speed and scale of an intrusion without removing the human attacker from the process.

One intrusion used around 1.4 billion input tokens

CrowdStrike reported that ARTEX’s planning agents consumed around 1.4 billion input tokens during a single intrusion.

Tokens are small units of text and other information processed by a language model. A model breaks instructions, system information and other input into these units before processing them.

The figure gives an indication of the volume of information handled by the agents during that operation. It does not represent 1.4 billion separate attacks, stolen files or compromised accounts.

It does, however, show how much model processing can be involved when multiple agents repeatedly examine information, plan actions and attempt different technical approaches.

CrowdStrike said the framework was used to pursue several attack paths in parallel, including activity involving web applications, cloud services, container environments, identity systems, email and VPN infrastructure.

In some cases, the agents moved to alternative approaches when an earlier attempt failed. That ability to keep working through different routes is one reason agent-based frameworks are attracting the attention of security researchers.

Google observed attacks happening in rapid bursts

CrowdStrike is not the only organisation to report the use of ARTEX in real-world intrusions.

In a separate report published on 30 October 2026, Google’s Threat Intelligence Group and Mandiant described threat actors using ARTEX, Hexstrike and CAIRN in multiple investigations.

The researchers observed activity that could happen in very short bursts. In one case, ARTEX generated 27 events in 23 seconds while probing AWS permissions across different security groups.

In another investigation, the framework used exposed application API calls to execute SQL commands and conduct further reconnaissance. The activity generated around 240 log events, with some errors potentially caused by multiple agents working on the same objective and overwriting one another’s actions.

These examples show both the speed and the limitations of agentic frameworks.

Some tasks can be attempted in seconds, but the resulting activity may also be noisy and generate large numbers of events. The Google and Mandiant findings do not mean every ARTEX operation succeeds at the same speed or produces the same results.

For defenders, the challenge is that familiar attack techniques can now be attempted in rapid, coordinated sequences. Security teams may have less time to identify and contain activity once an attacker has gained access.

A separate Dutch incident shows how quickly an attacker reached root access

A separate incident involving the Dutch Institute for Vulnerability Disclosure (DIVD) provides another example of ARTEX being used during an intrusion.

DIVD reported that an attacker first accessed its systems on 21 September 2026 by exploiting two previously unknown vulnerabilities in its Zammad helpdesk software.

The organisation detected malicious activity the following day, within 19 minutes, and blocked access to its data-centre systems.

In an update published on 31 October, DIVD identified ARTEX as the framework used during the incident. Its investigation said the attacker reached root privileges within 12 minutes of initial access.

Root access is a highly privileged level of control on a system. An attacker who obtains it may be able to access sensitive information, change system settings, install additional tools or move towards other systems, depending on the network and account permissions.

DIVD also reported more than 450,000 requests and over 2,500 scripts during the activity. It described the attack as noisy and messy, and said data had been exfiltrated from its systems.

The 12-minute figure refers to the time taken to reach root privileges after initial access. It should not be confused with DIVD’s separate statement that it detected malicious activity within 19 minutes.

There is also an important difference between the DIVD and CrowdStrike investigations. CrowdStrike’s recovered records showed a human operator steering ARTEX agents at decision points. DIVD described an agent that selected its next action after completing the previous one.

These are observations from two separate incidents. They show that the amount of human involvement can vary, rather than proving that every ARTEX operation works in the same way.

DIVD has not established that its incident was connected to VAPOR PANDA’s campaign. The two investigations should therefore be treated as separate cases.

ARTEX activity is not limited to one attacker

The wider concern is that ARTEX and similar frameworks are available to more than one threat actor.

Google and Mandiant reported seeing ARTEX, Hexstrike and CAIRN used in separate investigations involving different types of malicious activity. Their report also describes the continued use of open-source offensive frameworks and AI models to automate parts of the attack lifecycle.

CrowdStrike’s report describes VAPOR PANDA’s campaign, while DIVD’s investigation provides a separate example of ARTEX being used after an attacker gained access to a vulnerable system.

The original ARTEX repository was taken down by its creator in October 2026, according to Google’s report. However, the framework has continued to circulate through community forks and other versions, including projects identified as ScopeWeaver and ARTEX PRO.

Removing an original repository does not necessarily remove copies that have already been downloaded, modified or redistributed.

This makes the issue harder to address through a single takedown. Organisations need to focus on defending the systems and accounts that attackers may try to access, regardless of which framework they use.

What organisations should do

The reports do not suggest that organisations need an entirely new security strategy just because attackers are using AI. Many of the techniques described still rely on familiar weaknesses, including exposed services, compromised credentials, excessive permissions and systems that have not been properly secured.

However, the speed and coordination of agentic frameworks make it more important to detect suspicious activity early and limit what an attacker can do after gaining access.

Organisations should prioritise the following measures:

Security guidance

Six ways organisations can make attacks harder

AI tools can help attackers move quickly once they get inside a network. These practical steps can limit how far they get.

01

Keep admin systems away from public access

Login pages and management tools should not be open to everyone on the internet. Give administrators access through trusted connections and require strong sign-in protection.

02

Give accounts only the access they need

Staff accounts, applications and automated services should not have more permissions than their jobs require. Use credentials that expire when possible, and replace any that may have been exposed.

03

Keep important systems separate

An attacker who gets into one application should not automatically be able to reach company databases, identity systems or sensitive files. Network separation can help contain an intrusion.

04

Watch for unusual activity happening together

One unusual login may not tell the whole story. Security teams should look for a sequence of events, such as a strange login followed by internal scanning or unexpected access to company data.

05

Update internet-facing applications

Keep public-facing software and important systems up to date. Maintain a list of the applications the organisation uses so that forgotten or unsupported services do not remain exposed.

06

Keep security records somewhere attackers cannot easily change

Send system and login records to a protected central location. If an attacker gains administrator access to one machine, they should not be able to erase the organisation’s wider record of activity.

The central lesson is not simply that AI can make attacks faster. It is that organisations must be able to identify suspicious behaviour and restrict an attacker’s access before a foothold becomes a wider compromise.

Are ordinary users directly at risk?

The investigations described here focus mainly on organisations, government systems and business infrastructure. They do not establish that ordinary users’ personal phones or home computers were directly targeted in these particular campaigns.

However, individuals can still be affected when an organisation they use is compromised. A breach involving a company, public service or online platform may expose personal information, account details or contact data, depending on what the attacker accessed.

The DIVD incident is a reminder that even organisations involved in improving cybersecurity can be affected by vulnerabilities in software they rely on.

For individuals, the sensible precautions remain familiar: use unique passwords, enable multi-factor authentication where available, install security updates and be cautious about unexpected messages asking for login details or verification codes.

There is no need to assume that every AI-related cyberattack puts every personal device at immediate risk. The more useful approach is to understand which organisation or service was affected, what information was exposed and what action users are being asked to take.

What the investigations establish

What this means for cybersecurity

The ARTEX investigations show that AI-assisted offensive tools are moving beyond demonstrations and are being used in real intrusion activity.

They do not show that human hackers have become unnecessary or that AI systems can compromise any organisation automatically. The evidence instead points to a combination of human direction, automated agents, existing vulnerabilities and established hacking techniques.

That combination can still be dangerous. When several agents can investigate systems and attempt different actions in parallel, attackers may be able to cover more ground in less time.

For organisations, the priority is to make sure that one compromised account or vulnerable application does not become a route into the entire network. Strong access controls, timely updates, network separation and reliable monitoring remain essential.

AI has not changed the basic need to secure systems. It has raised the cost of leaving weaknesses exposed.

How We Checked This

This article is based primarily on three published investigations: CrowdStrike’s investigation of VAPOR PANDA’s use of ARTEX, Google Threat Intelligence Group and Mandiant’s analysis of agentic offensive frameworks, and DIVD’s public incident updates on its Zammad-related intrusion.

We have kept confirmed post-exploitation activity separate from targeting and credential-scanning activity. The DIVD incident is treated separately from the VAPOR PANDA campaign because the available reporting does not establish a connection between them.

Figures and timelines are attributed to the organisations that reported them.