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

At a glance

What this is: This is an Anomali briefing on SesameOp, a backdoor that abused legitimate developer tooling and the OpenAI Assistants API for covert command and control.

Why it matters: It matters because identity and access teams need to treat cloud APIs, developer utilities, and service identities as part of the control plane, not just the application layer.

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities - 46% confirmed, 26% suspected.
• 17 minutes
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months.

👉 Read Anomali's analysis of SesameOp, DragonForce, Gootloader, and related threats

Context

SesameOp sits at the intersection of malware tradecraft, developer tooling, and AI service abuse. The primary issue is not whether OpenAI’s platform was compromised, but whether a legitimate cloud API can be repurposed as a covert channel once an attacker already has a foothold. That is a familiar identity problem in a newer form: trusted service access becomes the transport layer for malicious activity.

For IAM and PAM teams, the lesson is that machine identities, developer processes, and external APIs now share the same trust boundary. Monitoring only interactive logins misses a major part of the attack surface, especially when persistent processes, web shells, and injected libraries can relay commands while appearing operationally normal.

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 service identities complicate detection of covert malware activity?

A: Service identities often have broad, persistent access and generate routine traffic that blends into normal operations. When malware runs under trusted processes or delegated credentials, logs can look legitimate unless teams correlate host behaviour, token use, and API calls. The risk rises when secrets, permissions, and process trust are managed separately.

Q: What do security teams get wrong about monitoring AI integrations?

A: They often monitor the application layer but not the identity layer behind it. An AI integration is only as safe as the tokens, service accounts, and hosts that can reach it. If those identities are not scoped tightly and baselined, attackers can abuse the integration as a stealth channel even without exploiting the AI platform itself.

Q: Who is accountable when a trusted cloud API is misused for intrusion activity?

A: Accountability usually sits with the organisation that owns the compromised environment and its delegated access paths, not with the API provider if no platform vulnerability was exploited. Governance should assign owners for service identities, API usage baselines, and detection coverage so abuse is investigated as an access-control failure, not just a malware event.

Technical breakdown

How AppDomainManager injection turns trusted binaries into loaders

AppDomainManager injection lets an attacker influence how a .NET process initialises by loading a malicious assembly through a trusted application path. In SesameOp, that mattered because the malware used Microsoft Visual Studio utilities and injected libraries to keep execution inside normal-looking developer workflows. The loader and managed component worked together to establish persistence, stage code, and hide execution behind familiar enterprise software. This is not about a novel exploit in the platform itself. It is about abusing application trust, process behaviour, and signed or expected binaries to evade basic alerting.

Practical implication: inspect .NET process-loading behaviour and image-injection events, not just obvious malware hashes.

Why API-based command and control is hard to distinguish from normal SaaS traffic

Command and control works by giving an attacker a reliable way to send tasking to infected systems and receive results back. SesameOp used the OpenAI Assistants API as a covert C2 channel, which means the traffic blended into legitimate API usage rather than looking like a classic beacon to a suspicious host. That shifts detection toward context, sequence, and identity. Security teams need to ask which service accounts, hosts, or processes should ever call that API, at what volume, and from which environment. Without that baseline, malicious use can remain hidden inside normal cloud and developer activity.

Practical implication: baseline API caller identity, call patterns, and environment provenance for every AI-facing service.

What persistent web shells and malicious processes reveal about dwell time

Web shells and persistent malicious processes are control points that let an intruder keep issuing commands long after initial access. In this case, Microsoft said the actors maintained access for several months, which indicates that the compromise was not a one-off execution event but an embedded operational foothold. Long dwell time usually means the defender lacks telemetry on process lineage, endpoint dwell detection, or service-to-service abnormality. It also means that identity evidence, such as token use, API access, or privileged service activity, can become more valuable than file-based indicators once payloads are established.

Practical implication: combine endpoint telemetry with identity logs to detect long-lived access that survives file-based cleanup.

Threat narrative

Attacker objective: The attacker wanted durable, low-noise remote control of compromised systems while hiding tasking and results inside legitimate service traffic.

1. Entry occurred after the actors established a foothold and deployed web shells and injected libraries into trusted Microsoft Visual Studio utilities. Credential access was not described as a direct password theft event, but the operation relied on persistent process control and trusted application misuse to keep command channels open.
2. Escalation came from maintaining execution through a loader and managed component that could relay commands, retrieve tasking, and return results through the OpenAI Assistants API. That pattern reduced visibility because the attacker used a legitimate cloud service as the transport layer.
3. Impact was long-term covert control of compromised systems for months, with malicious activity obscured inside normal enterprise and cloud traffic. The attacker objective was sustained remote execution and stealthy command-and-control persistence without triggering obvious platform abuse alerts.

NHI Mgmt Group analysis

AI API abuse has become a control problem, not just a usage policy problem. SesameOp shows that once an attacker has execution on a host, a legitimate AI-facing API can become a covert transport layer for tasking and exfiltration. That means security teams have to govern AI service access as part of identity and telemetry strategy, not merely as an application allowlist. The practical conclusion is that API identity, host provenance, and process lineage now belong in the same review cycle.

Developer tooling is now part of the identity attack surface. The compromise worked because trusted utilities, injected libraries, and web shells were able to coexist inside ordinary engineering activity. That is a reminder that software delivery tools often have implicit trust and broad permissions, which makes them attractive hiding places after initial access. For practitioners, this is where PAM, EDR, and software supply-chain monitoring overlap.

Covert C2 through trusted services creates a detection gap that traditional perimeter controls cannot close. If security teams only hunt for suspicious destinations or malware signatures, they will miss command traffic buried inside sanctioned API calls. Trusted-service concealment: a control gap where malicious activity hides inside approved cloud and SaaS traffic, defeating destination-based detection. The governance implication is clear: baseline legitimate service use before you can detect abuse.

NHI governance must extend to AI service identities and automation paths. Even when the AI platform itself is not compromised, the attacker can still weaponise the surrounding integration layer. That makes tokens, service accounts, and delegated process permissions critical control points. The practitioner conclusion is to treat every AI integration as a governed non-human identity with explicit scope and lifecycle oversight.

What this signals

Trusted-service concealment: the next operational problem for defenders is not simply malicious code, but malicious code riding inside approved AI and SaaS traffic. That shifts programme design toward identity-aware telemetry, process correlation, and API baselining, with OWASP Non-Human Identity Top 10 as a useful control map for the surrounding service identities.

Security teams should expect more abuse of legitimate developer and automation channels because those paths are already trusted, monitored inconsistently, and often over-privileged. The practical response is to treat every AI integration as a governed service identity, then verify it against the OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls.

The programme implication is straightforward: build detections around caller identity, process lineage, and token scope before an attacker turns your own integrations into command channels. If you are still relying on perimeter controls to catch this class of activity, you are watching the wrong layer.

For practitioners

• Baseline AI API usage by process and identity Map which hosts, service accounts, and developer tools are allowed to call external AI APIs, then alert on any new caller, new region, or unusual request pattern. Separate interactive developer access from service-to-service access so covert tasking is easier to spot.
• Hunt for .NET injection and web-shell persistence Prioritise detections for AppDomainManager injection, abnormal DLL loading, and web shell activity in developer and build environments. Correlate those events with unusual outbound API traffic to identify command channels that file-based scanners miss.
• Apply least privilege to AI-facing tokens and services Constrain every token used to reach AI or automation services to a single workload, a single purpose, and a short lifetime. Review whether those credentials can be rotated, revoked, and audited independently of user accounts.
• Correlate endpoint and identity telemetry for long dwell time Tie process creation, DLL loading, token use, and SaaS API access into one detection workflow so persistent access cannot hide behind normal operational noise. Months-long dwell time is often visible only when endpoint and identity logs are read together.

Key takeaways

• SesameOp shows that legitimate AI and developer services can be repurposed into covert command-and-control infrastructure once an attacker has host access.
• The scale of the problem is already visible in NHI research, where 72% of organisations report experienced or suspected NHI breaches.
• Practitioners should govern AI APIs, service identities, and process behaviour together, because the control failure is at the trust boundary, not only at the payload.

Key terms

• Covert Command-and-Control: Covert command-and-control is attacker communication designed to hide in legitimate traffic or trusted infrastructure. When blockchain or RPC channels are used for retrieval, the storage and control plane are separated, making the activity harder to disrupt with traditional takedown methods.
• 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.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Service identity baselining: Service identity baselining is the practice of defining which hosts, processes, and applications are allowed to use a given credential or token, then alerting on deviations. It helps defenders spot abuse of automation, delegated access, and API integrations that would otherwise look routine.

What's in the full analysis

Anomali's full post covers the operational detail this post intentionally leaves for the source:

• MITRE ATT&CK mappings for each malware cluster and intrusion stage
• The developer-tool injection sequence used by SesameOp and the supporting malware components
• The OpenAI Assistants API misuse pattern and how Microsoft described the covert channel
• The campaign context for DragonForce, SLH, Gootloader, and the other threats in the roundup

👉 The full Anomali post covers the SesameOp attack chain, API misuse detail, and the wider threat roundup.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It is designed for practitioners who need to connect identity controls to the realities of modern automation and AI integration.