“Black October” for AI Developer Platforms

At least nine AI Developer Platforms have disclosed incidents over the course of the month:

Wiz customers can refer to our relevant Threat Intel Center advisories for more information on the Railway Platform Breach,  Lightning AI Security Incident and the overall campaign. 

Fireworks, OpenCode, and Warp have all reported indications of an “agent swarm” attack. Andromeda’s incident report calls it part of an “industry-wide attack.” OpenCode and CommandCode have explicitly attributed their incidents to an attempt at “distillation.”

Any other month, and this would be the top security story. However, with all the ongoing incidents, few reports are connecting the dots across these attacks (Cloud Security Alliance as a notable exception).

The Pattern in these Attacks

Currently, most of these security incidents are still being analyzed, and detailed technical information is not available. Zeabur has shared a full write-up, and the company will be shutting down due to this incident. Railway has released a preliminary report and timeline. 

However, there are some indicative details. Fireworks, Zeabur, and Lightning all attribute their incident root causes to credential access. Lightning was previously impacted by a supply chain attack within the Mini-Shai Hulud campaign. Railway so far has shared they believe the initial access was via “privilege escalation in our build infrastructure,” while Warp has suggested the root cause was a third-party vendor dependency, and OpenCode attributes it to a “legacy system.”

All public reports highlight targeted exploitation, explicitly hunting stored environment variables, with a focus on those granting AI access. While there is no single vulnerability or dependency linking these attacks, the overall picture is strongly aligned with recent reports on two fronts:

Agentic Attacks, which can enable threat actors to compromise victims faster and more efficiently.

The rise of LLMJacking, and the associated infrastructure of LLM Brokers. These create a market that makes the theft easily monetizable, likely driving more actors to undertake operations to steal credentials. Distillation, notably alleged against Chinese AI labs, drives demand as well.

Impact and Follow-on activity

Reports on the impact of these attacks have so far been limited to anecdotal reports on social media, which include:

However, Wiz has been able to observe downstream abuse of enterprise credentials, whose compromise we can attribute to one of these vendor breaches. We will discuss an exemplary pair of such cases.

In both cases, we see abuse of keys that previously were heavily used from the infrastructure of a compromised vendor. 

They shared an identical first unauthorized activity, which happened within 30 minutes of the reported credential access within the vendor breach. It was a single InvokeModel from a residential IP address, in a one-minute sweep that tested stolen keys across multiple organizations. The call asked for Claude Fable 5.1, failed, and fell back to Opus 5.5, which worked.

In the days after this initial validation, both keys saw only a trickle of traffic: 14–120 calls a day from the same small Go client. The calls on the two keys ran in lockstep, about a minute apart. This indicates a single ongoing verification job checking that the keys remained valid.

Case A

Four days after the initial validation, a rotating proxy pool ran a catalog probe across dozens of addresses, sending one call per model across vendors: Amazon Nova, DeepSeek, gpt-oss, GLM, Kimi, Grok, GPT-6 Astra and older Claude models. Every call worked except Fable. A few hours later, a boto3 script on a residential address enumerated Bedrock and EC2 quotas. Twenty-two seconds after that, bulk traffic started from the same address. Within the next half hour, a second host mapped quotas and model availability across regions, making more than a thousand calls in under a minute.

The Flood

Over thirty hours, after which the key was remediated, the actor made approximately 800k Bedrock calls, and about 90% of them succeeded. The bulk ran first from the residential address and then, overnight, from a Level 3 hosting address. The key’s policy allowed global.* cross-region inference profiles, and the actor routed every call through them. Because global routing spread the load across regions, only about 6% of calls were throttled. Traffic leaned heavily on Opus: Opus models were three quarters of successful calls, led by Opus 5 (36%), Opus 5.5 (22%) and Opus 4.8 (10%).

Case B

Unlike Case A, this key was restricted. Seven days after the initial validation, it surfaced in an apparent reseller pool. Over four hours, thousands of failed calls came from rotating hosting addresses, each active for about 15 minutes. The calls failed because the key’s policy allowed Bedrock only through us.* cross-region inference profiles, and the pool requested global.*.

Early the next morning, a checker on a shared VPN exit identified the working us.* model IDs. Two hours later, a boto3 script on a Level 3 address retested global.* and us.* and enumerated Bedrock and EC2 quotas. It was the same script, down to the version string, that had probed Case A. Within minutes, the floodgates opened.

The Flood 

Over thirteen hours, after which the key was remediated, that single Level 3 address made approximately 1.7 million Bedrock calls, with over a million successful. Nearly all of the rest were throttled: without global routing, the traffic ran into the account’s regional quotas. Traffic was spread across a dozen Claude models and was less Opus-heavy than Case A. Opus 5.5, Sonnet 4.5 and Opus 5 made up three quarters of successful calls.

The Stolen Tokens

In both cases, the token usage profile resembles resold coding-agent traffic. A typical call sent only a handful of uncached input tokens, the signature of prompt caching, and got back a few hundred tokens of output. A long tail of calls carried tens of thousands of uncached input tokens, consistent with many different end users behind a reseller. At list price, these two cases alone likely ran up over $100k in usage.

What we see from these Attackers

Our research has been able to link the usage of the keys in the cases above overt reselling organizations. While we are not able to definitively establish the relationship between these reselling organizations and either the initial compromise or the “flood” token abuse documented above, the actors had access to the compromised keys and tested them from their infrastructure. The use of the keys by multiple actors suggests a robust market for this type of credential.

“momo” – Resale (and compromise?)

Wiz Research identified an actor centered around 23.106.46.239 who appears to refer to themselves as “momo” who had access to the keys used in Case A and Case B and is tied to an overt LLM resale site. Infrastructure linked to this IP address goes back to 2025 and has hosted multiple sites with titles related to LLM resale, including the site llm-routing.com which is currently active and advertises discounted access to frontier models, while accepting payment in USDT. This IP has also hosted an Artex landing page in mid-October and was publicly named by Zeabur as being part of their compromise. While we cannot definitively tie this operation to the “flood” of abuse documented above, the operator did have access to the stolen keys.

• The site momo.skin resolved to 23.106.46.239 in early 2026 and another site tied via passive dns (direct.465415.xyz), used the title “Moの自建网盘” (“Mo’s self-built cloud drive”). 

• In March of 2026, this actor begins advertising LLM related services, hosting sites with titles such as “ChatGPT Team 席位兑换” (“ChatGPT Team seat redemption”), and “ChatGPT 号池管理” (“ChatGPT account-pool management”). 

• On October 8, 2026, a subdomain (artex.nhhh.de) resolving to 23.106.46.239 hosted a page with the title “ARTEX — 自主渗透测试控制台” (“ARTEX — autonomous penetration testing console”). This is four days before Zeabur’s timeline identifying that IP address targeting their infrastructure (Oct 12 – 14). 

• In late October the 23.106.46.239 address conducts api key checks on the keys used in cases A and B and attempts a PutAccountDataRetention call using the Case B key. 

“Xingjiabi” – a second resale hub

Wiz also identified a second resale operation that was leveraging stolen keys. This one is publicly available at xingjiabiapi.org where they offer access to a wide range of frontier models for discount prices. Infrastructure tied to this site (38.246.114.118) was identified conducting permission checks on the keys used in both cases A and B. In both cases the checks were conducted after the high volume abuse of the key from unrelated ip addresses had already begun, suggesting that there is an active resale market for these keys.

• A subdomain of the main site, s3.xingjiabiapi.org resolved to 38.246.114.118 beginning on September 10, 2026. This 38.246.114.118 IP address enumerated the key used in case A, listing the inference profiles and models per region, paging through every bedrock quota. It also conducted a manual test of the key being used in Case B.

• One interesting note about this actor is they seem to be attempting to guard against distillation. Their domain was snapshotted hosting a page titled “蒸馏检测监控” (Distillation behaviour detection) that was designed to score users across three categories and attempt to sort them into “high risk”, “watch” and “normal”. This may indicate that the attackers are attempting to avoid being associated with distillation, potentially due to that activity leading to accounts being suspended.

IOCs

These IPs were used to test stolen keys and are suspected to be linked to LLM token abuse and resale. We do not have evidence that links them directly to the “Black October” attacks mentioned in this blog.

The following shared pools were also used for Bedrock abuse. However, either each compromised credential used a different IP address or the specific IPs rotated frequently: