SesameOp is a newly identified, stealthy .NET backdoor that exploits trusted cloud AI infrastructure—specifically OpenAI’s Assistants API—as a covert command-and-control (C2) channel. Discovered by Microsoft DART, this advanced threat blends into legitimate developer environments and HTTPS traffic, making detection extremely difficult. This advisory breaks down how the attack works, why it’s significant, and what defenders need to know to mitigate the risk.
Summary
SesameOp is a stealthy, fileminimal .NET backdoor identified by Microsoft DART that repurposes legitimate cloud AI infrastructure as a covert command and control channel. The intrusion uses a twocomponent implant — a loader (Netapi64.dll) and a .NET backdoor (OpenAIAgent.Netapi64) — that are obfuscated and injected into trusted developer tooling (Visual Studio components) via .NET AppDomainManager. Once active, the implant authenticates to the OpenAI Assistants API and abuses Assistants/vectorstore objects as a hidden message board: it retrieves small, encrypted and compressed command blobs, decrypts and executes them in memory (using an embedded JScript engine), then encrypts and uploads results back to the same service. Because communications occur over normal HTTPS to trusted domains, the activity blends with legitimate traffic and reduces disk artifacts, increasing detection difficulty. Microsoft and OpenAI coordinated to investigate the activity and disable the actor’s API key.
What makes this notable
- Unusual C2 channel: instead of hosting C2 infrastructure, the actor used OpenAI Assistants (vector stores / Assistants) as a relay/storage mechanism to fetch encrypted payloads and publish results. This hides malicious communications among legitimate API traffic and makes detection via standard domains harder.
- Stealth / defense evasion: heavy obfuscation (Eazfuscator.NET), .NET AppDomainManager injection into Visual Studio components, and compressed/encrypted payloads. The implant dynamically loads and executes code via JScript evaluation, reducing dropped artifacts.
Below the flow of a typical attack using this technique is described:
Attack vector and flow
- Initial access / drop of loader (Netapi64.dll) and implant artifact on dev host.
- Loader executed and injected into legitimate process (AppDomainManager into Visual Studio/tooling).
- Loader writes marker file (e.g., Netapi64.start) and unpacks embedded .NET implant.
- Implant reads embedded config (TextFile1) → extracts OpenAI API key, dictionary/assistant name, proxy.
- Implant creates mutex (OpenAI APIS) to avoid duplication.
- Implant authenticates to OpenAI Assistants/vectorstore endpoints (possibly via proxy).
- Implant lists assistants/vector stores → matches a host-specific Base64 ID or flag.
- Implant retrieves small Base64 blob (message or assistant content).
- Implant RSA-decrypts AES key → AES-decrypts blob → GZIP-decompress → yields script/module.
- Implant executes code inmemory (JScript Eval or dynamic .NET load).
- Implant captures output → AES/GZIP compress → uploads to assistant/vector store (result).
- Actor often deletes or updates the assistant/message (create → read → delete pattern).
- Implant sleeps and repeats (polling loop).
- Optional: persistence hardening, lateral movement, credential harvesting, or additional implants.
Indicators of compromise (IOCs)
- C:\Windows\Temp\Netapi64.start (file)
- DLL names: Netapi64.dll, OpenAIAgent.Netapi64 (loaded modules in dev tools)
- Strings in memory: OpenAIAgent, TextFile1, Eazfuscator.NET, embedded RSA public key patterns, long Base64 blobs
- Network: authenticated API calls to OpenAI Assistants/vector endpoints; rapidly created/deleted assistant/vector objects; Authorization header usage from unusual hosts/processes
- Process context: devenv.exe, msbuild.exe, dotnet, VBCSCompiler.exe loading unexpected .NET assemblies
Key takeaways:
This is a very sophisticated type of attack with focus on stealth to achieve a long-term persistence. Due to the complexity requiring an environment with both existing cloud AI API and developer tooling, the likely target profile is slightly limited. However, if these elements are present in your environment, make sure to take harden your environment.
- Not a CVE/patch issue: This is abuse of a service and compromised credentials, not a software vulnerability you can simply patch; mitigation is operational (keys, monitoring, policies).
- C2 via legitimate cloud APIs: The attacker used OpenAI Assistants/vectorstore objects as a covert message store — traffic looks like normal HTTPS to trusted domains, so domainblocking alone is insufficient.
- Credential and API key hygiene is critical: Compromised or overly broad API keys enable the attack. Keys should be scoped, rotated, auditlogged and revoked on suspicious activity.
Hardening actions:
API governance: limit, scope, and rotate API keys; centrally manage AI keys; require short expiry and perservice keys.
Network control for AI APIs: force AI API traffic through authenticated, logged proxies that record caller process/user metadata.
Harden developer hosts: separate dev tools from highvalue production systems; restrict who can run IDEs/build tools on sensitive hosts.
If you are worried about any of the threats outlined in this bulletin or need help in determining what steps you should take to protect yourself from the most material threats facing your organisation, please contact your account manager, or alternatively Get in touch to find out how you can protect your organisation.