SesameOp Backdoor

Researchers have uncovered a novel backdoor, tracked as SesameOp, that leverages the OpenAI Assistants API as an unconventional Command-and-Control (C2) channel. Rather than using typical network infrastructure or bespoke C2 servers, the malware abuses the Assistants API as a stealthy relay and storage mechanism to retrieve encrypted instructions and return execution results, allowing operators to blend malicious traffic with legitimate API requests.

How It Was Found

The implant was identified in July 2025 during an investigation of a sophisticated intrusion where unknown attackers had maintained footholds for several months. The researchers did not publish the identity of the affected organization. Follow-up analysis revealed a multi-layered intrusion with persistence mechanisms and in-environment components that collectively supported long-term access — behavior consistent with espionage objectives.

Technical Architecture

SesameOp's infection chain includes a loader DLL named Netapi64.dll and a .NET backdoor component labeled OpenAIAgent.Netapi64. Key technical characteristics:

• The DLL is heavily obfuscated with Eazfuscator.NET and designed for stealth and persistence.
• At runtime, the loader is injected into the host process via .NET AppDomainManager manipulation, triggered by a crafted .config file paired with the legitimate host executable.

The attackers also compromised Microsoft Visual Studio utilities by inserting malicious libraries, using an AppDomainManager injection technique to ensure persistence and code execution from seemingly legitimate toolchains.

Internal Tooling

Investigators described a 'complex arrangement' of internal web shells tied to persistent, strategically placed malicious processes. Those processes act as local orchestrators, executing commands relayed through the Assistants API and handing off tasks to other implanted components. The combined design kept the adversary's activity interwoven with normal developer and administrative tooling, making detection more difficult.

How OpenAI’s Assistants API Is Abused

The backdoor uses the Assistants API as a message store/relay. Commands are fetched from the Assistants list and interpreted via the description field; the implementation recognizes three instruction types:

SLEEP — instructs the implant to pause a thread for a specified interval.

Payload — directs the agent to extract code or instructions from the instructions field and run them in a separate thread.

Result — signals that execution output should be posted back to the Assistants API with the description set to 'Result', so the operator can retrieve the outcome.

Operational Flow

When active, the backdoor queries the Assistants API to retrieve encrypted commands. It decodes and executes payloads locally and then posts execution results back to the API as messages. This relay model turns a legitimate cloud AI API into an intermediary for issuing tasks and receiving outputs, effectively camouflaging attacker traffic within expected API usage patterns.

Attribution, Intent, And Strategic Objectives

At present, there is no public attribution for the campaign. The implant's emphasis on persistence, covert control, and long dwell time strongly suggests the attackers aimed for sustained access — consistent with intelligence collection or prolonged espionage activity. The case also demonstrates a broader trend: misuse of widely used, legitimate cloud services to evade detection and complicate incident response.

It's worth noting that the Assistants API is scheduled for deprecation in August 2026 and will be superseded by the Responses API, which may affect how similar abuse vectors operate in the future.

Takeaways

SesameOp is notable because it repurposes a mainstream AI integration endpoint into a covert C2 channel, combining .NET AppDomainManager injection, obfuscated DLLs, compromised development tooling, and internal web shells to achieve durable, hard-to-detect control. The campaign highlights the need for defenders to monitor unusual developer-tool behavior, anomalous use of cloud APIs from internal hosts, and signs of DLL injection or runtime manipulation in .NET environments.