SesameOp shows how AI APIs can mask long-term C2 activity

At a glance

What this is: Anomali says SesameOp is a backdoor that used injected Visual Studio libraries, web shells and the OpenAI Assistants API to hide command-and-control traffic inside legitimate cloud and developer workflows.

Why it matters: It matters because defenders increasingly need to monitor trusted APIs, developer tooling and machine activity as part of identity and access governance, not treat them as separate from compromise detection.

Context

SesameOp is an example of covert command-and-control hidden inside trusted tooling rather than obvious malicious infrastructure. The security gap is not only malware execution, but the abuse of normal developer and cloud service channels that often sit outside traditional identity review and alerting.

In this case, the attacker combined injected libraries, web shells and a legitimate API channel to preserve access and move tasking through systems that looked operationally normal. That makes the problem relevant to NHI governance because service-facing API use, authenticated automation and trusted software components can all become parts of the attack surface.

Key questions

Q: What breaks when attackers use legitimate AI APIs as command and control channels?

A: Detection breaks first. Traffic to a sanctioned API often looks like normal cloud usage, so destination filtering and basic proxy rules miss it. Teams need caller identity, process lineage, and environment baselines to distinguish legitimate automation from covert tasking. Without those controls, an attacker can hide command traffic inside approved service activity.

Q: Why do long-lived backdoors evade normal detection for so long?

A: Long-lived backdoors survive when they combine multiple control planes, such as web shells, injected processes and cloud API channels. Each element reinforces the others, so a defender may remove one path while the attacker retains another. The practical failure is siloed telemetry that does not connect endpoint, identity and service activity.

Q: What are the signs that a developer tool is being misused as an attack path?

A: Warning signs include unexpected command execution after opening a folder, local ports or deep links that accept attacker-controlled input, and workspace settings that alter binaries or commands. Another signal is when untrusted content is loaded into a privileged UI path. These patterns show the tool is interpreting project data as executable behavior instead of inert content.

Q: How should teams respond when legitimate SaaS or AI services are part of an intrusion?

A: Treat the service as part of the kill chain, not just as a communications path. Containment should cover session revocation, credential review, endpoint forensics and service-specific telemetry so the attacker cannot continue to use the same approved channel after cleanup. That is especially important when the service sits inside developer or automation workflows.

Technical breakdown

How AppDomainManager injection and injected libraries hide execution

AppDomainManager injection is a .NET execution-flow hijack technique that lets malware load before or alongside trusted application logic. In SesameOp, malicious libraries were injected into multiple Microsoft Visual Studio utilities, which means the attacker did not need to rely on a noisy standalone binary once the compromise was in place. That pattern matters because security telemetry often trusts signed developer tools and legitimate processes more than ad hoc malware. The result is execution that blends into everyday engineering activity and evades simple process-based detection.

Practical implication: monitor developer tooling for unusual module loads, parent-child process chains and abnormal in-memory code injection.

Why the OpenAI Assistants API became a covert command channel

The OpenAI Assistants API was not compromised as a platform. Instead, the attackers misused a legitimate API session as encrypted command-and-control, sending tasking to the malware and receiving execution results back through the same high-trust path. That matters because many defenders focus on blocking malicious domains while allowing approved SaaS and API traffic by default. When an API becomes the transport layer, traffic can look like normal application activity unless teams inspect identity, request pattern, timing and payload characteristics.

Practical implication: baseline legitimate API usage and flag unusual request cadence, tasking patterns and response sizes on high-trust developer or AI services.

How web shells and long-lived processes extend dwell time

Web shells create a persistent remote interaction point on a compromised host, while long-lived malicious processes keep the attacker connected even after initial entry. In SesameOp, those elements provided a durable control plane alongside the API channel, giving the operators multiple ways to re-enter or continue operations. That architecture is important because defenders may detect one channel and miss the others if monitoring is scoped too narrowly. The compromise therefore becomes a systems-and-identity problem, not just a malware-removal exercise.

Practical implication: tie web-shell detection, process persistence hunting and API anomaly monitoring into one incident workflow.

Threat narrative

Attacker objective: The attacker objective was to maintain stealthy long-term remote control of compromised environments while keeping command traffic hidden inside trusted services.

1. Entry occurred through compromised systems that hosted malicious web shells and injected components inside trusted developer utilities.
2. Credentialed or authenticated command traffic was then routed through the OpenAI Assistants API, allowing tasking to move over a legitimate service channel.
3. Escalation came from maintaining persistent malicious processes and repeated access over several months, which increased operator control and reduced visibility.
4. Impact was covert, durable command-and-control that let the actors sustain compromise while blending into normal enterprise and developer operations.

Breaches seen in the wild

• Microsoft Azure OpenAI abuse by Storm-2139: Storm-2139 used API keys leaked by Microsoft customers to hijack Azure OpenAI, bypass safety guardrails and resell access to generate harmful content.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Covert API abuse is now an identity governance problem, not only a malware problem. SesameOp shows that legitimate AI and developer APIs can become transport for command-and-control when authentication, request patterns and telemetry are not governed as part of the access layer. The lesson is broader than one backdoor: high-trust API channels need the same scrutiny as privileged accounts and service identities. Practitioners should treat sanctioned service use as governable identity activity.

Developer tooling is a privileged attack surface because it sits close to build, test and release workflows. When malicious libraries are injected into tools such as Visual Studio utilities, defenders lose the clean separation between engineering work and hostile execution. That creates a blind spot for organisations that monitor endpoints but not the software supply and runtime context of developer machines. The practical response is to view developer environments as identity-rich systems with elevated trust.

Persistent malware often succeeds by combining multiple low-friction control planes. Web shells, injected processes and a legitimate cloud API together create redundancy that makes removal harder and detection less deterministic. This is the same structural lesson seen across modern intrusion tradecraft: attackers do not rely on one channel when they can stack several. Control-plane blending: the attacker's use of ordinary services to carry malicious tasking makes traffic classification alone insufficient. Security teams must correlate identity, endpoint and API signals.

AI service abuse is likely to increase as more business workflows depend on authenticated model and assistant endpoints. The risk is not that AI APIs are inherently insecure, but that they inherit trust from the surrounding enterprise and are rarely governed with the same rigor as interactive user access. That creates a gap between service legitimacy and adversary misuse. Practitioners should plan for abuse of approved AI services as a standing detection scenario, not an edge case.

What this signals

Control-plane blending: defenders need to assume that legitimate AI and developer services can be repurposed as covert infrastructure. The practical shift is to correlate endpoint, identity and API telemetry so that approved services are judged by behaviour, not trust alone.

Service accounts, automation endpoints and approved cloud APIs should all be treated as governable access paths. If the organisation cannot explain which processes are allowed to talk to which services, it cannot reliably separate routine automation from adversary tasking.

For practitioners

• Hunt for API-driven C2 patterns Correlate cloud API requests with endpoint process trees, looking for tasking loops, small encrypted payload exchanges and unusually regular polling from compromised hosts.
• Inspect developer endpoints for injected modules Review Visual Studio and other developer tools for suspicious DLL loads, AppDomainManager manipulation and process injection that can hide inside trusted engineering workflows.
• Baseline legitimate AI and SaaS API usage Build normal profiles for assistant, automation and developer-service calls so that unusual cadence, geography, payload size or response timing stands out quickly.
• Unify web-shell and persistence response Treat web shells, persistent processes and API misuse as one incident path so containment removes every control channel, not just the most obvious one.

Key takeaways

• SesameOp shows that covert access can be sustained by combining injected developer tooling, web shells and a legitimate AI API channel.
• The important evidence is not only the backdoor itself but the months of access that remained possible because trusted services were abused as infrastructure.
• Defenders need joint visibility across endpoints, identities and API usage so that approved services can be investigated when their behaviour stops looking normal.

Key terms

• AppDomainManager injection: AppDomainManager injection is a .NET abuse technique that alters how a trusted process loads code at startup. Attackers use it to insert malicious logic into otherwise legitimate binaries, letting them inherit trust, blend into normal execution, and evade simplistic file-based or signature-based detection.
• Command-and-control: Command-and-control is the communication channel an attacker uses to issue instructions to malware and receive results back from a compromised host. For XWorm, the channel is encrypted and used for session management, payload delivery, surveillance, and modular expansion of capabilities after compromise.
• Web shell: A web shell is a script placed on a server that accepts commands over HTTP and executes them on demand. It creates persistent server-side access, which means defenders may remove the original exploit path while the attacker still retains a reusable foothold.
• Covert Channel: A covert channel is any communication path that hides its true purpose from normal security controls. In DNS tunneling, the protocol remains legitimate, but the content being exchanged is not, which makes behavioural inspection essential for detection.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners build the governance muscle needed to control service identities and automation safely.