By Marçal Santos, CISO and founder of SecureLeap. CISM and CDPSE (ISACA). Previously security roles at Aircall, Citibank and Talkdesk. 20+ years in cybersecurity.
ARTEX is an open-source agentic AI penetration testing framework: a team of AI agents that maps a target, finds weaknesses, exploits them and writes a report, with little human input. It was built in China to help defenders, won a Chinese AI attack-and-defense competition in September 2026 and was free on GitHub. Within weeks, attackers had used it to break into South Korean banks and Japanese companies, and Microsoft says a China-aligned group used it to try sign-ins at more than 2,250 Microsoft 365 tenants through compromised ConnectWise cloud apps.
The surprising part is not the AI. No source reports a zero-day in any ARTEX attack. The agents found what people had left open: forgotten web portals with SQL injection, accounts without strong sign-in protection and vendor apps with too much access. That is good news for startups, because those are gaps you can close this month.
Quick answer: ARTEX is an autonomous, multi-agent penetration testing tool that can run on Claude, GPT, DeepSeek and other AI models. Its developer released it as open source for defensive testing, but attackers used it in September and October 2026 against at least 7 South Korean financial firms (counts range from about 67,000 people to 100,000 records, and one bank alone reported card data of 119,000 clients), 20 to 80 Japanese companies depending on the source, and a Microsoft 365 supply chain campaign attributed to the China-aligned group Storm-0940. The attacks relied on known weaknesses at machine speed, so the defenses are known too: inventory your exposed apps, enforce MFA, audit vendor access and keep your logs.
The story is still moving. Every figure below is shown as its source reported it, with a link, and the sources table at the end lists who said what and when.
ARTEX at a glance
What is ARTEX?
ARTEX is a multi-agent penetration testing system driven by large language models (LLMs). It is not an AI model itself. It is the harness that tells AI models what to do: you give it a target, and it calls models such as Anthropic's Claude, OpenAI's GPT or DeepSeek to plan the attack, run security tools and decide the next step from the results (Seoul Economic Daily, Microsoft).
Penetration testing tools are nothing new. What makes ARTEX different is that the agents chain the steps together on their own. A human pentester decides what to try after each scan; ARTEX lets an AI model make that call at machine speed, across many targets at once.
How ARTEX works
Zscaler's analysis and Microsoft's describe the same loop:
- A planner agent splits the engagement into tasks, such as mapping subdomains or testing a login page.
- Worker agents run real tools against the target, such as the nmap network scanner bundled in its Docker image (Zendot), and send the results back to the model.
- Every finding goes into a graph of assets and vulnerabilities, which the AI model reads to choose the next action.
- A reporting agent writes up the findings it could validate.

ARTEX shipped with one guardrail: a default blocklist that stops it from targeting government entities and universities. Financial institutions were not on the list (Zscaler). Its web console runs in English, Korean, Mandarin, Spanish or Japanese (Microsoft).
Who built ARTEX, and is it still available?
ARTEX was written by Li Puhua, a Chinese security engineer known online as Autumn (GitHub handle Autumn-27), who previously worked as a threat detection engineer at the Chinese security firm Threatbook. He built it as a personal side project for organizations to test their own networks, and released it under the AGPL-3.0 open-source licence (Seoul Economic Daily, Zendot).
After the Korean bank breaches made the news, the developer added a usage rule that bans malicious use, then made the GitHub repository private on 8 October 2026 and said updates would stop. That does not take ARTEX off the internet: every copy and fork downloaded before then still works (Zscaler). Threatbook co-founder and CEO Xue Feng has since announced that ARTEX "is back, with a commercial edition", as part of a cloud platform called RedAgent.ai (Seoul Economic Daily).
Why agentic AI changes the attack math
Most of what these agents do, a skilled human attacker could already do. Three things change when agents do it:
- Speed. Microsoft saw cases where Storm-0940 went from first targeting to privileged cloud access in under 3 hours, with sign-in attempts at 2,900 per minute and more than 200 sign-ins in under 4 minutes using 4 stolen app credentials (Microsoft). As Microsoft Threat Intelligence put it, "Agents are not constrained by factors affecting humans."
- Scale. Each extra target costs the attacker almost nothing. Earlier in 2026, a Chinese-speaking attacker used off-the-shelf AI agent frameworks to hit up to 100 companies in five days and steal more than 600,000 card records, for a total outlay of about $8,000 (Quartz).
- Skill. The operator needs far less hands-on skill, because the model picks and runs the exploits. The Korean attacker even ran Claude Code sessions with Chinese-language prompts and asked Claude where to sell Korean breach data and how to find Korean Telegram sales groups (CrowdStrike).
What has not changed is the type of weakness the agents exploit. AI makes attackers faster at finding the same old gaps; it has not, in any reported ARTEX case, found new ones. CrowdStrike's assessment is that "adversaries will likely continue to experiment with implementing AI tooling in their operations" (CrowdStrike). If you have read our post on the risks of AI agents inside your own company, this is the other side of the same shift: the agents now work for attackers too.
"AI did not invent a new way into these companies. It found the forgotten portal, the vendor app with admin rights and the account without MFA faster than any human team could. For a startup, that makes the basics urgent, not optional," says Marçal Santos, CISO and founder of SecureLeap.
3 real attacks that used ARTEX
1. South Korean banks (late September to early October 2026)
An unidentified, likely Chinese-speaking and financially motivated attacker used the tool against South Korean financial firms from late September 2026 (CrowdStrike). The agents did not go after core banking systems. They probed peripheral web apps: at one bank, a loan progress inquiry service used by financial brokers; at another, an employee mobile work-support system. They broke in with SQL injection and authentication bypass, then pulled names, phone numbers, annual income figures and loan limits (Zscaler).
The traffic came through more than 20 IP addresses in over 10 countries, including the United States, Japan and Germany (Seoul Economic Daily). South Korea's National Police Agency opened an investigation, and President Lee Jae Myung told officials that "speed is of the essence" (Quartz). CrowdStrike traced the activity to a server that hosted an ARTEX instance next to an open directory of Claude Code files.
Mun Chong-hyun, who leads the Genians Security Center in Seoul, flagged ARTEX as a likely tool soon after the breaches surfaced. He said attacks powered by AI agents "have been increasing in South Korea" and that he expects them to "grow in number worldwide" (Quartz).
2. Japanese companies (18 September to 18 October 2026)
Investigating leaks for its clients, GMO Cybersecurity by Ierae found an ARTEX server that had targeted about 20 Japanese companies, 9 of them in the same industry. Eight of those companies had announced information leaks in September and October. GMO found 6 more AI-driven attack servers aimed mainly at Japanese insurance, finance, e-commerce, logistics and retail firms (GMO via Rocket Boys). Japanese media put the total at about 80 affected companies and reported ARTEX traces on all 6 servers, which GMO itself has not confirmed (Seoul Economic Daily). GMO did not name the flaws the attackers exploited.
GMO named two weaknesses the attackers relied on: checking only versions with a published CVE, and relying on a web application firewall (WAF) to block attacks instead of fixing the application.
3. Storm-0940 and the ConnectWise supply chain compromise (September to October 2026)
On 21 October 2026, Microsoft attributed a large campaign to Storm-0940, a China-state aligned group active since 2021, and said it used the tool to run its usual playbook at machine speed (Microsoft). It came in two phases:
- A password spray that failed. From 10 to 14 October, the agents fired more than 151,000 failed logons at 327 Microsoft 365 accounts across 8 organizations, peaking at 2,900 failures a minute. Account lockouts and sign-in protections held: Microsoft saw no successful sign-in.
- A vendor's keys that worked. The group then took control of several ConnectWise cloud applications, including Cloud Backup, that customers had already authorized in their Microsoft 365 tenants. Using that existing trust, the agents tried to sign in to more than 2,250 tenants, then used Microsoft Graph for reconnaissance, added credentials to apps for persistence and changed users, groups and admin roles. One ConnectWise management app was used to give itself the Global Administrator role.
Microsoft says the activity did not come from a flaw in its own products. Its report also does not explain how it identified ARTEX in this activity; it points to the speed and volume of the attacks. ConnectWise published its first advisory on 16 October, and Microsoft's report lists the affected application IDs and the sign-in logs to check.

How many victims? It depends who you ask
The figures do not agree, because each source counted something different: firms, people, records or targets. Here is what each one reported:
Being targeted is not the same as being breached. Microsoft notes that most of Storm-0940's attempts failed, and that a successful sign-in by an affected app does not prove data was taken (Microsoft).
What the ARTEX attacks have in common
Put the three cases side by side and the AI looks less like magic and more like a very fast intern working through a checklist. Every entry point the sources describe was a known, preventable weakness:

- Forgotten web apps. A broker loan portal and an employee mobile backend are exactly the systems nobody lists in the security plan. They were online, connected to customer data and vulnerable to SQL injection and authentication bypass, which are among the oldest bugs on the web. Authorization flaws like these are also hard for scanners to see (business logic flaws explained).
- Bulk reads that nobody noticed. The Korean attacker pulled tens of thousands of records out of portals such as a loan inquiry service. Zscaler advises alerting on sequential lookups and high record counts per session on partner and employee portals.
- Trusted vendors. Storm-0940 failed to guess its way in, then walked in through apps the victims had approved themselves. A vendor with tenant-wide permissions is part of your attack surface (SOC 2 vendor management for startups).
- Basics worked where they were in place. The 151,000-attempt password spray got nothing. Lockouts and sign-in protection did their job, even at machine speed.
8 steps startups should take now
These steps are for a startup with 10 to 200 people, a Microsoft 365 or Google Workspace tenant and a public web app or API. Each one closes a gap these attackers used. Most take hours, not weeks.

1. List every internet-facing app, including the forgotten ones
Why: the Korean banks lost data through side systems, not their main platforms, and GMO's first advice is an inventory of exposed web systems, APIs, admin panels and legacy apps (GMO via Rocket Boys).
How: pull every DNS record and cloud load balancer, and list each hostname with an owner and what data it can reach. Look hard for staging environments, old admin panels, partner and broker portals, and mobile app backends. Anything with no owner gets shut down or put behind single sign-on. Our startup security risk assessment guide explains how to build that asset inventory so legacy systems surface.
2. Enforce authorization on the server, and rate-limit lookups
Why: SQL injection and authentication bypass were the way in at the Korean banks, and portals such as a loan inquiry service then gave up tens of thousands of records.
How: use parameterized queries everywhere; check on the server, for every request, that the user may see that record; cap how many records one session can read per hour; and return only the fields the screen needs. Then alert when one session walks through IDs in sequence (Zscaler).
3. Turn on MFA everywhere and block legacy sign-in
Why: Storm-0940's 151,000-attempt password spray failed. Protections that stop a human attacker also stop an AI one.
How: require MFA for every account, starting with admins, and prefer phishing-resistant methods (passkeys or security keys) for admins. In Microsoft 365, block legacy authentication with security defaults or a Conditional Access policy. In Google Workspace, enforce 2-Step Verification for all users.
4. Audit vendor and MSP apps by App ID, not by name
Why: the ConnectWise apps already had the keys to customer tenants. Microsoft tells responders to search by application ID, because display names can be changed or duplicated (Microsoft).
How: in the Microsoft Entra admin center, open Enterprise applications, set the application type filter to all applications and review each app's permissions, especially anything that can read all mail, write to the directory or manage roles. In Google Workspace, go to Security, then Access and data control, then API controls, and review the configured third-party apps (Google). Remove what you no longer use, and ask your managed service provider (MSP) and backup vendor exactly which permissions their apps hold and why.
5. Alert on new app credentials and admin role grants
Why: Storm-0940's persistence came from adding credentials to apps and granting admin roles, including an app giving itself Global Administrator.
How: set alerts on three events: a credential or secret added to an app or service principal, any assignment of an admin role, and mass downloads or new mail forwarding rules. In Microsoft 365, use alert policies or Microsoft Defender; in Google Workspace, use activity rules in the security center or the alert center. At minimum, send these alerts to a shared channel that someone reads every day.
6. Keep logs longer than you think you need
Why: Microsoft told affected customers to review service principal sign-ins back to 1 October 2026, three weeks before its report. By default, Microsoft Entra ID Free keeps sign-in and audit logs for 7 days, and P1 and P2 keep them for 30 days (Microsoft Learn). Upgrading later does not bring old logs back.
How: export identity, web, authentication and database logs to storage or a SIEM and keep them for at least 90 days. GMO gives the same advice for web and database logs, so you can spot probing and bulk data reads after the fact.
7. Fix the application, not just the WAF rule
Why: GMO found that relying on WAF blocking instead of fixing the app was one of the two gaps attackers used in Japan. An agent will try hundreds of payload variations until one slips past a rule.
How: treat a WAF rule as a stopgap with an expiry date, and track the code fix as its own ticket. Check end-of-life products and related versions too, not only versions with a published CVE.
8. Write the first hour of your incident plan: save evidence, then revoke
Why: Microsoft's first instructions to affected customers were to disable the connection but not delete the enterprise app, and to preserve sign-in and audit logs before making changes that cannot be undone. Deleting first destroys the evidence you need to know what was accessed.
How: write down who can disable a vendor connection, where logs get exported and who calls your lawyer and cyber insurer. Then run a 30-minute tabletop exercise: "our backup vendor's app was compromised last night". Our post on common startup security mistakes has a simple incident plan outline.
Common mistakes
- "We are too small to be a target." Agents make extra targets nearly free. Storm-0940 tried more than 2,250 tenants through one vendor; it did not pick them one by one.
- Scanning only for known CVEs. SQL injection in a custom portal has no CVE number. GMO flagged CVE-only checks as one of the two gaps in Japan.
- Treating a vendor as safe because it is well known. A trusted vendor's app is trusted by your tenant too. Review its permissions as if it were a new hire with admin rights.
- Deleting the compromised app first. You lose the evidence of what it touched. Disable, preserve, then remove.
- Running AI security tools without vetting them. Zscaler advises treating open-source pentest harnesses as hostile code: run them isolated from production, keep production credentials out and review any fork before you run it. Forks of the tool are still circulating.
Sources
This post draws on primary research from Microsoft, CrowdStrike, Zscaler and GMO, plus news reports from Korea and the United States. Primary research is listed first:
Links: Microsoft, CrowdStrike, Zscaler, GMO via Rocket Boys, Seoul Economic Daily, 8 October, Seoul Economic Daily, 20 October, Quartz, Zendot. The Seoul Economic Daily articles are AI-translated from Korean, and figures from The Wall Street Journal, BleepingComputer, Yomiuri Shimbun and NHK are cited as these outlets reported them. Where sources disagree, this post shows each figure with its source rather than picking one.
FAQ
What is ARTEX?
ARTEX is an open-source agentic AI penetration testing framework that uses a team of AI agents, running on models such as Claude, GPT or DeepSeek, to scan a target, exploit weaknesses and write a report with little human input. It was built in China for defensive testing and was later used by attackers against banks in South Korea, companies in Japan and Microsoft 365 tenants worldwide.
Is ARTEX malware?
No, ARTEX is a legitimate security testing tool, in the same family as other open-source pentest frameworks, and it only attacks the targets its operator points it at. The danger is that it lets one attacker with little skill run many intrusions at machine speed.
Who created ARTEX?
Chinese security engineer Li Puhua, known online as Autumn, released ARTEX on GitHub as a personal side project for organizations to test their own networks. He made the repository private on 8 October 2026, after it was linked to the South Korean bank breaches.
Is ARTEX still available?
The public repository is closed, but copies and forks downloaded before 8 October 2026 still work, and a commercial cloud edition has been announced. Plan your defenses on the assumption that attackers still have it.
Can small companies be targeted by AI-driven attacks like ARTEX?
Yes, because agents make each extra target almost free to attack: Microsoft saw one group try sign-ins at more than 2,250 Microsoft 365 tenants through a single vendor. Small companies are most exposed through forgotten web apps, accounts without strong MFA and third-party apps with broad access.



