1. Executive summary
OpenAI has disclosed an adversarial distillation campaign that ran from 1 July 2026, peaked on 24 and 25 July with 16,000 extraction-pattern requests from over 4,000 accounts, and was disrupted on 28 July. OpenAI attributes the "core cluster" of the activity to individuals associated with China's Moonshot AI, the developer of Kimi, though it states it cannot confirm that all operators in the window belonged to a single rival. No CVE, no CISA KEV entry and no MITRE ATT&CK profile for Moonshot AI exist in our verified reference data, so the attribution is unconfirmed and the item carries no exploitable software vulnerability. The direct risk to EMEA financial services is low: this is a model-IP and AI-safety dispute between vendors, not an intrusion into client infrastructure. The indirect risk is contractual and third-party, because the same bulk-query technique can be pointed at any AI service a firm exposes to users or embeds in a product.
2. Regulatory framing
No specific DORA/NIS2 article is directly engaged by this item. The trigger facts here are a vendor's terms-of-service enforcement action and an unconfirmed attribution to a foreign AI developer. Neither changes what an EMEA financial services client must do under DORA or NIS2 on its own. The table below records the two articles a client should re-read only if it operates or procures the affected class of service; the trigger is the client's own exposure, not the OpenAI disclosure.
| Article | Trigger (the fact in this item) | Practical impact |
|---|---|---|
| DORA Art. 28: ICT third-party risk, general principles | A firm contracts an external AI model provider whose service was the target of scaled extraction by third parties | The firm must be able to evidence due diligence on that provider's controls against bulk extraction and account abuse; the OpenAI case is a worked example of what to ask about |
| NIS2 Art. 21(2)(d): supply chain security measures | The firm's AI capability is delivered through a supply chain that includes a model provider and its API resellers | Supply chain measures should cover the provider's account-abuse controls and its ability to detect coordinated extraction, not just uptime and confidentiality |
3. Technical analysis & attack chain
This is a threat-campaign item with no exploited vulnerability. The mechanism is abuse of a legitimate API, not a software flaw. The confirmed sequence, per OpenAI's account as reported:
- On 1 July 2026, query volume against OpenAI models began at low rate using a repeated extraction pattern.
- Volume built through July, then spiked on 24 and 25 July to 16,000 requests using a relevant extraction pattern, originating from more than 4,000 users.
- OpenAI investigated and identified related prompt-pattern activity across more than 15,000 users.
- OpenAI banned the model-copying accounts, tightened signup and infrastructure controls, and expanded monitoring.
- OpenAI closed a pathway that let someone who already held another user's encrypted reasoning replay it and recover its contents.
- OpenAI disrupted the campaign on 28 July and worked with service providers to stop the activity relocating to third-party services.
What the operators did not do, on OpenAI's own statement: they did not break encryption, compromise a database, or gain direct access to stored user conversations. The technique was to manipulate model interactions so that protected reasoning was reproduced in a form visible to the requester, at scale, in violation of terms of service. That distinction matters for defenders: there is no malware, no implant, no persistence mechanism and no command-and-control channel described in the source. The "attack" is bulk API consumption shaped to elicit reasoning output.
The one technical detail with defensive value is the replay pathway. OpenAI says it closed a route by which a party already in possession of another user's encrypted reasoning could replay it and recover the contents. The source does not name the endpoint, the token format, the model versions affected, or the fix. OpenAI did not answer The Register's question about which models were targeted. Treat the replay pathway as a described-but-underspecified control gap: the class of bug is a confused-deputy or replay weakness in reasoning-object handling, and the specific implementation is not public.
Attribution. OpenAI says it is unclear whether all operators in the July window were linked to one rival, but that the core cluster came from Moonshot AI. This is a single-source claim resting on OpenAI's own investigation, reported by The Register, and Moonshot AI did not respond to a request for comment. Our verified reference data holds no MITRE ATT&CK profile for Moonshot AI, so we treat the attribution as unconfirmed. The Register also notes that in late July Michael Kratsios, Assistant to the US President for Science and Technology, accused Moonshot AI of building its Kimi K3 model by distilling Anthropic's Fable, and that Anthropic shipped a distillation defence called "preserved thinking" with Fable 5.1 and Claude Opus 5.5. Those are separate claims from separate parties and do not corroborate OpenAI's technical findings.
4. Mitigation & containment
This item does not require emergency action against client infrastructure. The steps below address the exposure a firm has if it operates or consumes an AI model service.
P1 (within 24h)
- If your firm exposes a model API to external users, pull the last 30 days of per-account request volume and flag any account whose request rate or prompt-pattern similarity indicates scripted bulk extraction. The OpenAI figures give you a scale reference: 16,000 requests from 4,000 accounts in a two-day spike.
- Confirm with your model provider whether it has closed a reasoning-object replay pathway of the kind OpenAI describes, and get that in writing. If the provider cannot confirm it, treat stored reasoning objects as readable by any party that can obtain a reference to them and restrict sharing of those objects.
P2 (within 72h)
- Review the account-abuse controls on any AI service you resell or embed: signup verification, per-account and per-IP rate limits, and detection of repeated prompt patterns across accounts. OpenAI's response was to tighten signup and infrastructure controls and expand monitoring; ask your provider to evidence the equivalent.
- Check your AI provider contracts against DORA Art. 30 key contractual provisions if the service is material to a regulated function, specifically the provider's obligation to notify you of terms-of-service enforcement actions and account-abuse incidents that touch your tenant.
P3 (within 7 days)
- Add bulk-extraction detection to your own AI gateway logs if you proxy model traffic: alert on a single account exceeding a request-rate threshold, and on high cross-account similarity in prompt structure.
- Where you depend on a model provider's safety guardrails as a control, document that a distillation-style extraction is designed to reproduce capability without those guardrails, and that the control therefore does not transfer to any model trained on the extracted output.
5. Indicators of compromise
No indicators of compromise available in the source material. The source names no hashes, domains, IP addresses, file paths, registry keys or account identifiers. The activity is described only in aggregate counts.
Behavioural indicators
| behaviour | where to observe | confidence |
|---|---|---|
| Sustained low-rate extraction-pattern queries building to a high-volume spike (16,000 requests from 4,000+ accounts over two days) | Model provider API access logs, per-account request metrics | High for the OpenAI incident as described; the pattern is generic to any API |
| Related prompt-pattern activity spread across more than 15,000 accounts | API logs correlated by prompt structure rather than by account | Medium; OpenAI states it identified this, but the detection method is not published |
| Replay of another user's encrypted reasoning object to recover its contents | Model provider reasoning-object handling and access logs | Medium; OpenAI confirms the pathway existed and was closed, but gives no endpoint or token detail |
6. Detection
Insufficient indicators to author detection rules. The source provides no file artefacts, command lines, mutexes, registry keys, scheduled-task names or network values. The only usable signal is aggregate request-rate behaviour, which is environment-specific and belongs in the behavioural table in §5 rather than in a signature.
7. Sources
- The Register, "Irony alert: OpenAI whines that Chinese model stole its special IP that it stole from everybody else", https://www.theregister.com/security/2026/09/30/irony-alert-openai-whines-that-chinese-model-stole-its-special-ip-that-it-stole-from-everybody-else/5300285, 2026-09-30.
8. Adverse Trace position
We assess this as a low-severity item for EMEA financial services clients. There is no CVE, no CISA KEV entry and no MITRE ATT&CK profile for the named actor in our verified reference data, so the Moonshot AI attribution is unconfirmed and rests on a single source, OpenAI's own investigation as reported by The Register; verify before acting on it. The client impact is contractual and third-party rather than technical: firms that expose or consume model APIs should confirm their provider has closed a reasoning-object replay pathway and has account-abuse controls that would catch coordinated bulk extraction. We will monitor for a Moonshot AI response, for any published technical detail on the replay pathway, and for evidence that the same extraction technique is being pointed at financial-sector AI services, and will reissue if any of those change the assessment.
Published via PulseTrace — Adverse Trace threat intelligence.