Amazon’s threat sensors captured operating records from ARTEX hacking agents that were hunting AI-model credentials, expanding cloud access and attempting to defeat cryptocurrency identity checks, according to new research published November 13. In the largest campaign, stolen API keys were fed back into the attackers’ own model gateway, letting compromised accounts pay for the inference used to search for more keys.
The records reached Amazon through MadPot, its global network of decoy services, between October 3 and November 5. Some sensors presented themselves as popular large-language-model APIs. ARTEX treated them as inference backends and sent the context its agents needed to continue working: standing instructions, task history, tool calls, findings and the state of a shared knowledge graph.
That gave Amazon an unusually detailed view of how the campaigns were organized. The company assessed with moderate confidence that disparate Chinese-nexus groups operated them, based on simplified-Chinese prompts, China time-zone settings, targeting patterns and infrastructure. However, Amazon did not observe every claimed intrusion directly and could not independently verify all outcomes recorded by the agents. It notified AWS customers where its evidence supported doing so.
The same day, the FBI issued a TLP:CLEAR alert on ARTEX, warning that the framework has been used globally since at least August across finance, government, technology, defense, energy, healthcare and other sectors. The bureau said some intrusions progressed from initial targeting to privileged access in under three hours.
How ARTEX turned stolen keys into operating budget
ARTEX is a multi-agent penetration-testing framework written in Go. It does not include a model of its own. Instead, operators connect it to services such as Claude, GPT, DeepSeek, GLM, Grok or Kimi and give it a high-level objective. Planner, worker, verification and compression agents then divide the work and write their results into a persistent knowledge graph.
In the campaign described by Amazon Threat Intelligence, the objective was not simply to find generic cloud access. The agents prioritized credentials that unlocked premium frontier models. Working keys went into a managed pool that powered later ARTEX tasks, creating a feedback loop: steal model access, spend the victim’s quota to find more model access, then grade the new credentials by reach and available balance.
The agents looked for internet-facing AI gateways and application builders that often sit between users and upstream model providers. Amazon named One API, New API, Veloera, Sub2API and LiteLLM, along with Dify, FastGPT, Langflow, RAGFlow, Open WebUI, LobeChat and Ollama.
A product fingerprint selected the next attack path. The recorded playbook included unclaimed installations, anonymous management endpoints, default administrator credentials, LiteLLM’s default master key, Langflow’s CVE-2025-3248, RAGFlow’s CVE-2026-28797, an isCliRequest authentication bypass affecting the One API family, server-side request forgery against cloud metadata services, and secrets exposed through JavaScript bundles, source maps, debug routes or environment files.
Discovery extended beyond live applications. The agents searched GitHub repositories and event archives, npm and PyPI packages, container-image layers, notebooks, model-hosting spaces, paste sites and Telegram channels. They then validated identities through provider token services, enumerated storage, checked permission scope and probed managed model services, secret stores and application identities.
Amazon saw the campaign’s memory, not every claimed breach
The evidence needs a precise reading. MadPot recorded requests made to Amazon-controlled decoys, but the agents’ context also described work on systems outside Amazon’s visibility. Those histories show what the operators instructed ARTEX to pursue and what its agents reported doing. They do not independently prove every successful access claim written into the knowledge graph.
Amazon’s telemetry is still valuable because it exposes the operating model. Instructions sent one operation through a fixed sequence of countries, told it to favor enterprise production systems over personal projects and required every credential to be graded. A lead was classed as L1, a working API call as L2 and access with quantified data or spend as L3. Credentials that had been public for more than 30 days were treated as low-value inventory.
The FBI’s alert connects that method to a broader campaign history. It cited attacks against South Korean financial institutions that exposed information on about 67,000 people and the ConnectWise Cloud Backup supply-chain compromise that opened a path to more than 2,250 downstream tenants. The bureau said the original developer withdrew the public repository in October, but forks, archived copies, localized versions and a commercial edition remain available.
Internet measurements also show how widely the tooling spread. Censys counted 1,465 exposed ARTEX hosts on November 4, although roughly 650 were concentrated in two uniform hosting blocks and may not represent distinct operators. Of the total, 155 also carried another threat detection, including other AI attack frameworks, Cobalt Strike, Vshell or Adaptix C2. Thirty-two ARTEX hosts exposed open directories containing exploit and post-exploitation tools.
The deepfake campaign failed its recorded liveness tests
A second ARTEX operation targeted identity verification at two cryptocurrency exchanges. Four agent sessions worked in parallel on cash-out routes, account balances, a real-time deepfake pipeline and the verification bypass.
The agents reverse-engineered one vendor’s face-position event stream and movement coordinate system. Their closest recorded attempt placed the synthetic face within seven pixels of the target, but the server-side liveness verdict rejected every attempt preserved in the records. On a consumer GPU, a separate pipeline reached 11.5 frames per second by splitting an open-source face-animation model and reducing memory copies.
Document work ran alongside the video effort. The agents tried to make altered identity images resemble untouched camera files by matching synthetic metadata to the JPEG’s real dimensions and retaining the original camera compression tables. The records show a serious, technically specific attempt, not evidence that the exchanges’ checks were ultimately defeated.
What defenders can detect after ARTEX changes its IPs
Static indicators have a short shelf life because ARTEX is frequently forked and operators rotate infrastructure. Behavior lasts longer. Palo Alto Networks’ Unit 42 observed bursts of one to 14 requests about a second apart followed by pauses of 25 to 31 seconds, consistent with a model call between action cycles. In one case, more than 200 client secrets were validated in about three minutes.
Other patterns included immediate use of routes found in OpenAPI specifications and source maps, corrected retries seconds after HTTP 422 errors, a read after nearly every successful write, storage-bucket write-and-delete tests, placeholder usernames before real ones and identical attack sequences repeated about 30 seconds apart. One operation polled every 48 seconds for three days.
Those signals are not proof on their own. A fast scanner or a human with automation can produce some of them. Taken together across an identity, application and cloud trail, they can distinguish an autonomous loop from ordinary user traffic.
Six checks for AI gateway and cloud teams
- Inventory every model gateway and builder. Find internet-accessible LiteLLM, Dify, Langflow, RAGFlow, Open WebUI, Ollama and similar services, including development and staging systems. Confirm ownership, current version and whether the management plane is reachable without a VPN or identity-aware proxy.
- Remove default and long-lived credentials. Replace vendor defaults, rotate upstream model keys, move secrets out of client bundles and environment files served by web applications, and block direct access to cloud metadata services. Do not assume a public key will be revoked automatically.
- Require authentication on every write path. Review provider-configuration routes, import and URL-fetch features, debug endpoints, initial-setup flows and APIs generated from OpenAPI specifications. A forgotten staging endpoint can hold the same upstream keys as production.
- Watch model usage like cloud spend. Alert on unfamiliar models, sudden token or cost increases, new countries, abnormal concurrency and calls from workloads that do not normally use AI services. Compare gateway logs with provider-side usage rather than relying on one view.
- Hunt cloud control-plane drift. Look for token validation followed quickly by storage enumeration, secret-store access, OAuth credential changes, new SSH keys, Elastic IP allocations, unexpected compute instances and write-then-delete permission tests. Preserve evidence before removing access.
- Detect the cadence, not just the address. Correlate rapid retry-and-correct cycles, model-length pauses, immediate testing of newly found routes, parallel probing of unrelated edge systems and repeated verification calls. Import the current IP indicators from Amazon and the FBI, but treat them as leads rather than durable signatures.
ARTEX did not invent new classes of vulnerability. The campaigns depended on exposed administration surfaces, old flaws, default credentials and secrets left where automated discovery could reach them. What changed was the operating tempo: multiple agents could test weak points in parallel, share what they learned and act on a credential within minutes. That compresses the window between exposure and abuse, especially for AI services whose keys are both valuable and immediately spendable.
