Notifications
Clear all
Topic starter
02/08/2026 12:18 pm
TL;DR: Microsoft’s DART team found SesameOp, a backdoor that used injected libraries, web shells, and the OpenAI Assistants API as an encrypted command-and-control channel while maintaining access for months, according to Anomali citing Microsoft. The case shows that legitimate AI and developer services can be abused as covert infrastructure when identity, process, and API monitoring are weak.
NHIMG editorial — based on content published by Anomali: Anomali Cyber Watch covering SesameOp, DragonForce Cartel, Gootloader malware, and related threats
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, redentials are exposed publicly, attackers attempt access within an average of 17 minutes - and as quickly as 9 minutes in some cases.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months.
Questions worth separating out
Q: What breaks when attackers use legitimate AI APIs as command and control channels?
A: Detection breaks first.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read Anomali's analysis of SesameOp, DragonForce, Gootloader, and related threats →
OpenAI Assistants API abuse in SesameOp: what should defenders watch?
Explore further
02/08/2026 1:19 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: SesameOp shows how AI APIs can mask long-term C2 activity
