Historical intelligence backfill. This assessment covers reporting originally published on 2025-11-03 and was added to the RWP archive on 2026-09-07.
SesameOp did not hack OpenAI — it used Assistants API as a dead-drop the proxy would allow
Microsoft DART found a .NET backdoor fetching encrypted commands from OpenAI's Assistants API during a months-long intrusion discovered in July 2025.
Bottom line up front
CONFIRMED Microsoft DART, publishing 3 November 2025, described SesameOp, a .NET backdoor found in July 2025 inside a multi-month intrusion. A component named along the lines of OpenAIAgent.Netapi64 did not run OpenAI models. It used the Assistants API as storage/relay: pull encrypted compressed commands, run them (Integrity360 reports an embedded JScript engine), post results. Microsoft says this is misuse of intended API capability, not an OpenAI product vulnerability. OpenAI disabled the actor's API key; the account had not been using models beyond limited API calls.
Historical backfill of 3 November 2025 reporting; intrusion discovered July 2025 with months of prior dwell; added 7 September 2026.
What happened
Loader path Microsoft described: .NET AppDomainManager injection, obfuscation (Eazfuscator.NET), a Netapi64.dll loader plus the OpenAI-named backdoor DLL. The Register notes Visual Studio / developer-tooling injection in secondary write-ups. Message types reported in coverage: SLEEP, payload, result.
DART also saw internal web shells feeding commands into the same environment. The AI API was the stealthy C2, not the whole intrusion.
Microsoft and OpenAI jointly investigated. That cooperation is CONFIRMED. Actor attribution beyond "sophisticated, long dwell": UNKNOWN in the public blog.
Why it mattered
Secure web gateways still treat api.openai.com as productivity. After 2023's "use GitHub/Slack/Google as C2" wave, this is the same living-off-trusted-services trick with a 2025 brand.
Two wrong lessons:
- "OpenAI was breached." Microsoft explicitly said no.
- "Block all OpenAI." Maybe for some plants. For everyone else, the control is which identities and hosts may call which API keys, plus egress allow-lists that do not equal "the whole vendor."
Assistants API's later deprecation path (noted in secondary coverage toward August 2026) does not retire the idea. Any LLM vendor with object storage or thread APIs is a candidate dead-drop.
Who / what was affected
CONFIRMED at least one Microsoft IR customer with months of dwell.
UNKNOWN victim sector, count, and whether the implant was sold or bespoke.
Developer workstations and app servers that already have outbound HTTPS to AI APIs are the realistic host class.
Technical context
Detection that does not need the sample:
- Unexpected processes calling OpenAI (or other LLM) APIs with Assistants/threads/vector-store verbs, especially from servers that are not your chatbot.
- API keys in binaries or config outside the official SDK inventory.
- AppDomainManager injection / unexpected .NET native images next to Visual Studio or line-of-business .NET apps.
- Web shells plus outbound AI API — correlate, do not silo.
RWP will not document the encryption layers or injection recipe beyond what Microsoft already chose to publish.
Exploitation / threat status at the time
CONFIRMED implant, API abuse, key disablement.
REPORTED obfuscation and in-memory execution details in IR vendor advisories.
UNKNOWN reuse after the key kill; whether other AI APIs were used in parallel.
What defenders should have done
- Inventory sanctioned AI API keys; alert on new keys and on hosts that have never called the API.
- Egress: allow OpenAI from the app that needs it, not from every workstation and certainly not from servers in the PCI or OT-adjacent VLAN.
- Hunt AppDomainManager and unsigned .NET sidecars on admin/dev boxes.
- Assume "AI traffic" in proxy logs needs a content/destination review, not a category allow.
- If you find a key in malware, rotate it with the vendor the way Microsoft/OpenAI did — and search for siblings.
What we know now
The Assistants API sunset does not end LLM-API C2. Treat this as a pattern assessment: trusted SaaS object stores as botnet mailboxes.
RWP assessment
Confidence: High on Microsoft's core claims. Moderate that most enterprises still cannot name which servers are allowed to talk to which AI APIs.
Novel channel, old doctrine: if the proxy allows it, C2 will use it.
Defensive actions
- AI API allow-list by identity and host.
- Secret scan for
sk-/ vendor keys in binaries. - IR tabletop: "web shell plus api.openai.com, no model usage in the product."
- Do not write detections that look for the DLL name alone; names change.
Sources
- Microsoft Threat Intelligence — SesameOp: Novel backdoor uses OpenAI Assistants API for command and control
- The Register — Microsoft: OpenAI API moonlights as malware HQ
- Integrity360 — Threat Advisory: SesameOp backdoor
- Cyberwarzone — Microsoft discloses SesameOp backdoor abusing OpenAI API