Julien Vehent on cloud security, risk management and web services engineering.
by Julien Vehent
tl;dr: The recent ARTEX campaigns didn’t rely on frontier models or zero-day exploits. They paired an open-source orchestration framework written in Go with mid-tier, open-weight models to automate classic living-off-the-land (LOTL) and API abuse techniques at scale. When attackers run open-weight models on their own infrastructure, vendor account takedowns no longer work as a control. Defenders need to focus on non-human identity management, strict server-side authorization, and probabilistic correlation across multiple signals.
ARTEX is an open-source, multi-agent penetration testing system written in Go and released in July 2026. Its agents execute a full penetration test from reconnaissance through exfiltration with minimal human involvement. Importantly, it’s an orchestration layer, not a model: it simply drives whichever LLM you point it at.
Between late September and early October, seven South Korean financial institutions disclosed breaches. ThreatBook’s compilation of the Korean reporting describes attackers finding endpoints that returned sensitive fields, substituting business identifiers to enumerate valid records, and repeating the queries in bulk. CrowdStrike recovered ARTEX configuration files and session histories from the operators’ own infrastructure, which is how the tooling was identified.
Then, on October 21, Microsoft reported that Storm-0940, a China-state-aligned actor, used ARTEX in a supply chain compromise of a ConnectWise multi-tenant application. The agents authenticated into customer tenants as a trusted application, with no interactive sign-in required. Microsoft recorded several cases where the actors gained privileged cloud access in under three hours from initial targeting.
From a security engineering perspective, two things stand out. First, the techniques aren’t new: password spraying, OAuth application abuse, Graph reconnaissance, and bulk secret reads. Second, the entry points in Korea were a loan-progress inquiry service and an employee mobile work-support system—classic broken object-level authorization (IDOR) flaws we’ve been writing findings about for twenty years.
The ARTEX operators ran DeepSeek v4.1-flash as their primary backend, with GLM-5.3 and Grok 4.6 in supporting roles. For defenders, that architecture choice is the most important takeaway from these incidents.
Nearly every AI disruption story we’ve celebrated since 2024 depended on the model being hosted by a provider willing to turn it off. Microsoft and OpenAI disabled accounts belonging to five state-affiliated actors in February 2024. OpenAI reported disrupting more than forty malicious networks by October 2025. Anthropic detected and shut down a Chinese state-sponsored campaign that had run roughly 80 to 90 percent autonomously. Those are real wins, but they also highlight a control that only exists while the attacker chooses to be a customer.
Open weights remove that dependency entirely. There’s no account to suspend, no centralized usage pattern for a provider to flag, and no abuse team to notify. The Cloud Security Alliance made this point directly in its ARTEX research note: because models can be run locally, defenders shouldn’t rely on model-vendor safeguards to stop this activity. In fact, GTIG has already observed a China-linked actor deploying local open-weight models inside compromised cloud environments—meaning the inference is happening on your own compute, under your identities, and inside your network egress.
We’ve seen this trajectory building for a while. In June 2025, GTIG identified APT28’s PROMPTSTEAL querying Qwen2.5-Coder-32B-Instruct through the Hugging Face API to generate commands during live operations against Ukraine. It was the first malware observed querying an LLM in the wild. It didn’t need a frontier model; it just needed a model good enough to answer.
I want to come back to what I wrote last month about detection fidelity, because the ARTEX campaigns illustrate the problem quite clearly. The user agents Microsoft observed were python-requests, Python-urllib, and curl. The Korean intrusions consisted of well-formed API queries against services built to answer those queries. This is living off the land at the application and control-plane layer, with no malware binary to catch and no high-fidelity tripwire to trip.
Looking at where the signal actually lived in the Korean bank intrusions, the traffic came from dozens of addresses across several countries. No single request looked anomalous on its own. Instead, the intrusion only became visible when looking at the co-occurrence of weak signals:
Taken individually, each of those looks like normal application traffic. Together, they’re a breach. This goes back to the argument I made a year ago about probabilities and low signal-to-noise. When you’re dealing with an agentic attacker, correlation isn’t a nice-to-have optimization on top of your rule engine—it is the detection. There is no single deterministic event waiting to fire an alert, because the attacker is using your own interfaces the exact way they were designed to be used, just faster than a human operator would and from dozens of places at once.
The attacker’s marginal cost per target is collapsing, while the detection cost per alert hasn’t moved and volume is increasing.
The practical question to ask our engineering and detection teams isn’t whether we’re ready for AI attackers in the abstract, but instead to focus on something narrower and testable: if an agent ran a thousand well-formed queries against our customer-facing APIs from thirty rotating addresses over four days, what signals would our pipeline correlate, and who would get paged?
The answer is likely not one you’ll be comfortable with…
tags: