Microsoft Incident Response – Detection and Response Team (DART) researchers uncovered a new backdoor that is notable for its novel use of the OpenAI Assistants Application Programming Interface (API) as a mechanism for command-and-control (C2) communications. Instead of relying on more traditional methods, the threat actor behind this backdoor abuses OpenAI as a C2 channel as a way to stealthily communicate and orchestrate malicious activities within the compromised environment. To do this, a component of the backdoor uses the OpenAI Assistants API as a storage or relay mechanism to fetch commands, which the malware then runs.

The backdoor, which we’ve named SesameOp, was discovered in July 2025, when DART researchers responded to a sophisticated security incident, where the threat actors had maintained a presence within the environment for several months prior to the engagement. The investigation uncovered a complex arrangement of internal web shells, which were responsible for running commands relayed from persistent, strategically placed malicious processes. These processes leveraged multiple Microsoft Visual Studio utilities that had been compromised with malicious libraries, a defense evasion method known as .NET AppDomainManager injection.

Hunting across other Visual Studio utilities loading unusual libraries led to the discovery of additional files that could facilitate external communications with the internal web shell structure. Analysis of one such artifact identified SesameOp, a covert backdoor purpose-built to maintain persistence and allow a threat actor to stealthily manage compromised devices. The stealthy nature of SesameOp is consistent with the objective of the attack, which was determined to be long term-persistence for espionage-type purposes.

This blog post outlines our analysis of SesameOp and its inner workings and highlights the capability of threat actors to adjust their tactics, techniques, and procedures (TTPs) in response to rapid technological developments. We’re sharing these findings with the broader security research community to help disrupt this backdoor and improve defenses against this and similar threats.

This threat does not represent a vulnerability or misconfiguration, but rather a way to misuse built-in capabilities of the OpenAI Assistants API, which is being deprecated in August 2026. Microsoft and OpenAI jointly investigated the threat actor’s use of the OpenAI Assistants API. DART shared the findings with OpenAI, who identified and disabled an API key and associated account believed to have been used by the actor. The review confirmed that the account had not interacted with any OpenAI models or services beyond limited API calls. Microsoft and OpenAI continue to collaborate to better understand and disrupt how threat actors attempt to misuse emerging technologies.

Technical analysis

Our investigation uncovered how a threat actor integrated the OpenAI Assistants API within a backdoor implant to establish a covert C2 channel, leveraging the legitimate service rather than building a dedicated infrastructure for issuing and receiving instructions. Our analysis revealed sophisticated techniques employed to secure and obfuscate communications, including payload compression to minimize size, as well as layered encryption mechanisms both symmetric and asymmetric to protect command data and exfiltrated results.

The infection chain consists of a loader (Netapi64.dll) and a NET-based backdoor (OpenAIAgent.Netapi64) that leverages OpenAI as a C2 channel. The dynamic link library (DLL) is heavily obfuscated using Eazfuscator.NET and is designed for stealth, persistence, and secure communication using the OpenAI Assistants API. Netapi64.dll is loaded at runtime into the host executable via .NET AppDomainManager injection, as instructed by a crafted .config file accompanying the host executable.

Netapi64.dll loader

Netapi64.dll is obfuscated with Eazfuscator.NET, a tool used to obfuscate .NET applications. The DLL creates the file C:\Windows\Temp\Netapi64.start as a marker. It also creates a mutex to ensure that only one instance is running in memory. Any exceptions with an error message are written to C:\Windows\Temp\Netapi64.Exception.

Figure 1. Netapi64.dll enumerates files in Temp directory

The *Netapi64.dll *loader enumerates the files under *C:\Windows\Temp* and checks for a file ending with .Netapi64. The loader then XOR-decodes the file and runs it.

Figure 2. Decoding and invoking the SesameOp backdoor

OpenAIAgent.Netapi64 backdoor

Microsoft security researchers determined that the malware component OpenAIAgent.Netapi64 contains the main functionality that enables the backdoor to operate. Contrary to its name, OpenAIAgent.Netapi64 does not utilize OpenAI agent software development kits (SDKs) or model execution features. Instead, it uses OpenAI Assistants API to fetch commands, which the malware then decrypts and executes locally. Once the tasks are completed, it sends the results back to OpenAI as a message. To stay under the radar, it uses compression and encryption, ensuring both the incoming payload and the outgoing results remain hidden.

Figure 3. Core method that invokes backdoor functionality

At launch, it creates the mutex OpenAI APIS, reads the configuration from the .NET resource section TextFile1 of the executable, and parses it:

||

The configuration is split using a pipe (|). The first part (OpenAIAgent.token) contains the OpenAI API key and the second part (OpenAIAgent.aaazzz) is used by the embedded .NET module as a dictionary key selector. The third part (OpenAIAgent.proxy) specifies the proxy address.

Figure 4. Extracting config from .NET resource section

The code checks if the third part of the configuration specifies a proxy address; if present, it utilizes this address. In the absence of proxy details, the system defaults to using the default web proxy system.

Figure 5. Configuring proxy settings

The backdoor obtains the hostname and applies Base64 encoding. If the hostname is unavailable, it uses NAMEXXX as a placeholder.

First, the backdoor queries the vector store list from OpenAI using the OpenAI Assistants API and the hardcoded API key. The backdoor also checks if the vector store name contains hostnames by parsing the response. If, for example, the host is communicating for the first time, OpenAI would not have the hostname, so it would create a vector store using the hostname of the infected machine.

Figure 6. Creating or requesting vector store ID

The vector store list retrieved from OpenAI might look like this:

Figure 7. Vector store list from OpenAI

Next, it retrieves the list of Assistants created in the OpenAI account, of up to 100 Assistants, with pagination controlled by the limit query parameter. From the response, it populates Assistant ID, name, description and instructions variables.

In the context of OpenAI, Assistants refer to a feature within the OpenAI platform that allows developers and organizations to create custom AI agents tailored to specific tasks, workflows, or domains. These Assistants are built on top of OpenAI’s models (like GPT-4 or GPT-4.1) and can be extended with additional capabilities.

Figure 8. Retrieving Assistants list

An Assistants list retrieved from OpenAI might look like this:

Figure 9. Assistants list from OpenAI

In the response above, the description field is set to SLEEP. The description field contains one of the following three options:

• SLEEP
• Payload
• Result Figure 10. Command options

When the description is set to SLEEP, the backdoor reads the instruction value and splits the string with [._.] as delimiter. The first element is the thread ID and the second element is the message ID. The backdoor retrieves the message from OpenAI using both the thread ID and message ID.

Figure 11. Reading message from OpenAI

The message retrieved from OpenAI using thread ID and message ID might look like this:

Figure 12. Message retrieved from OpenAI

The backdoor parses the timeSLEEP field from the response received from OpenAI. The value is then used to perform a thread sleep operation.

Figure 13. Retrieving timeSLEEP value

In the Assistants list, if the description field contains Payload, the backdoor retrieves the message from OpenAI using the thread ID and message ID extracted from the instructions field and deletes the message and the Assistant using message ID and Assistant ID, respectively.

Figure 14. Processing the message retrieved from OpenAI

After the message is read from OpenAI, the backdoor invokes a separate thread for execution.

Figure 15. Invoking separate thread to process payload

The invoked thread begins parsing the message. The message consists of two parts separated by a space. The message is split into an array of two elements:

• The first element is a 32-byte AES key, which is Base64-decoded and decrypted using a hardcoded RSA private key.
• The second element is Base64-decoded, decrypted with AES algorithm using the key derived from the first element, and decompressed with GZIP. Figure 16. Decrypting and decompressing the payload

The decrypted message undergoes additional processing and is converted into a dictionary through the following steps:

1. Split by ampersands (&): The decrypted message is divided using & as the delimiter, with empty entries removed.
2. Split each pair by equal sign (=): Each resulting substring is split by = with a maximum of 2 parts to separate keys from values.
3. URL decoding: Both the key and value are decoded using HttpUtility.UrlDecode() with UTF-8 encoding to handle special characters. Figure 17. Transforming the message into dictionary

After converting the final message into a dictionary and retrieving the OpenAIAgent.aaazzz key from the configuration, both are passed as parameters to the executeWithJScriptEngine method.

The method first checks whether OpenAIAgent.httpApplicationState[“MicroWxx”] is null. If it is null, the code Base64-decodes and GZIP-decompresses the embedded .NET module. Using reflection, the backdoor then dynamically loads this module and calls the Frameworks method with the provided parameters. If MicroWxx is already present in the Application State (i.e., the check for null fails), the code skips the decoding and decompression steps of embedded module and directly loads and executes the method retrieved from Application State.

Figure 18. Invoking embedded module to execute payload

The Frameworks method initializes a Microsoft JScript VsaEngine, then loops through the message dictionary (DicT) to construct a NameValueCollection. It retrieves a key from the configuration (Pwd) and uses this key to find the corresponding value in the collection. This value is then executed using Eval.JScriptEvaluate, and the result of this execution is returned to the original caller of the module.

Figure 19. Executing payload using Eval.JScriptEvaluate

After launch, a 32-byte AES key is created. The result is first compressed with GZIP, then encrypted using AES with this key, and finally encoded in Base64. The AES key itself is encrypted using a hardcoded RSA public key found in the backdoor, and this encrypted key is also Base64-encoded. Both the encrypted key and the processed result are joined together, separated by a space character.

Figure 20. Compressing and encrypting results

The processed result is posted to OpenAI as a new message with the same thread ID retrieved earlier from description field.

Figure 21. Posting the results as message to OpenAI

The backdoor creates a new Assistant with the Base64-encoded hostname as Assistant name. The thread ID and the new message ID, where the results are posted to, are concatenated using the delimiter [._.]. The instruction field is set to the concatenated thread ID and message ID and description field is set to Result. This signals to the actor that the result obtained by executing the payload is ready.

Figure 22. Creating Assistant using Base64-encoded hostname

Finally, it performs a POST request to vector store using the vector store ID.

Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the impact of this threat.

• Audit and review firewalls and web server logs frequently. Be aware of all systems exposed directly to the Internet.
• Use Windows Defender Firewall, intrusion prevention systems, and network firewall to block C2 server communications across endpoints whenever feasible. This approach can help mitigate lateral movement and other malicious activities.
• Review and configure your perimeter firewall and proxy settings to limit unauthorized access to services, including connections through non-standard ports.
• Ensure that tamper protection is enabled in Microsoft Dender for Endpoint.
• Run endpoint detection and response in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode.
• Configure investigation and remediation in full automated mode to let Microsoft Defender for Endpoint take immediate action on alerts to resolve breaches, significantly reducing alert volume.
• Turn on potentially unwanted applications (PUA) protection in block mode in Microsoft Defender Antivirus. PUA are a category of software that can cause your machine to run slowly, display unexpected ads, or install other software that might be unexpected or unapproved.
• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques.
• Turn on Microsoft Defender Antivirus real-time protection.

Microsoft Defender XDR detections

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence.

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects this threat as the following malware:

• Trojan:MSIL/Sesameop.A (loader)
• Backdoor:MSIL/Sesameop.A (backdoor)

Microsoft Defender for Endpoint

The following alerts might indicate threat activity related to this threat. Note, however, that these alerts can be also triggered by unrelated threat activity.

• Possible dotnet process AppDomainManager injection

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following prebuilt promptbooks to automate incident response or investigation tasks related to this threat:

• Incident investigation
• Microsoft User analysis
• Threat actor profile
• Threat Intelligence 360 report based on MDTI article
• Vulnerability impact assessment

Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.

Hunting queries

Microsoft Defender XDR

Microsoft Defender XDR customers can run the following query to find related activity in their networks:

Devices connecting to OpenAI API endpoints

//show number of devices connecting to https://api.openai.com per InitiatingProcessFileName, and number of days in the period where the connection was observed
DeviceNetworkEvents
| where RemoteUrl endswith "api.openai.com"
| summarize Connections = count() by DayOfConnection = bin(TimeGenerated, 1d), DeviceName, InitiatingProcessFileName, RemoteUrl
| summarize TotalConnections = sum(Connections), DaysWithConnections = dcount(DayOfConnection), DistinctDevices = dcount(DeviceName) by InitiatingProcessFileName, RemoteUrl

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

Microsoft is committed to delivering comprehensive customer experience through various Microsoft offerings. Our approach goes beyond traditional support by focusing on detection, prevention, and in-depth mitigation to help customers quickly respond to security incidents and build resiliency. Check our Unified and Security eBook and visit https://aka.ms/Unified