When malware talks to its operator through a cloud AI service API, the command channel looks like the AI traffic your organisation already allows. MITRE ATLAS tracks this as AML.T0096 AI Service API, in the Command and Control tactic (AML.TA0014): the adversary embeds commands, and often results, in the normal traffic of an AI service reachable from the victim system. The only case study ATLAS links so far is SesameOp, a backdoor Microsoft's incident responders found relaying commands through the OpenAI Assistants API. This guide covers what makes AI API command and control different from other web service C2, how to find it in proxy, endpoint and AI provider telemetry, the egress and key governance that shrinks the space it can hide in, and how to respond. It is for SOC analysts, network and proxy owners, and the teams that run AI access for the business. For general C2 detection, see the Command and Control (C2) Guide.
Key takeaways
- The channel is a legitimate API used with the attacker's key. In SesameOp the malware carried its own API key, so traffic went to the real provider endpoint over TLS and blended with sanctioned use.
- Which process calls the AI endpoint matters more than the domain. Microsoft's own hunting guidance counts devices connecting to the AI API endpoint by initiating process; a Visual Studio utility or a service binary calling an AI API is the anomaly.
- Funnel AI traffic through one controlled path. If only an AI gateway, sanctioned clients and named workloads may reach AI provider endpoints, any other direct connection becomes a high-fidelity signal.
- Your keys versus foreign keys is a detectable difference. A gateway or TLS-inspecting proxy that knows your organisation's tenants and keys can flag requests that authenticate as someone else's account.
- Takedown needs the provider. SesameOp's channel ended when OpenAI disabled the API key and account involved. Report abuse to the provider as part of containment.
How the technique works
ATLAS describes AML.T0096 as adversaries communicating using the API of an AI service on the victim's system, with commands and results embedded in normal traffic. ATLAS calls the channel covert because it blends in, notes that using existing infrastructure lets the adversary live off the land, and states that AI service APIs may be abused as C2 channels for stealthy, long-term espionage. ATLAS rates the technique as realised. It is the AI-specific counterpart of ATT&CK T1102 Web Service, covered in the T1102 Web Service Defensive Guide.
The SesameOp case (AML.CS0042)
According to Microsoft's November 2025 write-up, its Detection and Response Team found SesameOp in July 2025 during an incident where the actor had been present for several months. The points that matter for defenders:
- Execution: a loader was injected through .NET AppDomainManager injection (ATT&CK T1574.014) using a crafted .config file next to a compromised Visual Studio utility.
- Channel: the backdoor carried a hardcoded API key in its resources and used Assistants, threads and messages as a mailbox. The Assistant description field acted as a state flag (sleep, payload waiting, result ready), commands arrived as message content, and results were posted back as messages.
- Protection of the channel: commands and results were compressed and encrypted (AES with RSA-wrapped keys), so content inspection of the API payload would not reveal readable commands.
- Clean-up: ATLAS records that SesameOp deleted the Assistants and messages it created, which removes evidence on the provider side.
- Not a product flaw: Microsoft stated the threat does not represent a vulnerability or misconfiguration but misuse of built-in API capabilities. The model was never asked to do anything; the API was storage and relay.
OpenAI's deprecations page lists the Assistants API for removal on 26 August 2026, with the Responses and Conversations APIs as the replacement. The lesson outlives that API: any AI service with stored objects (threads, files, vector stores, conversations) or even plain request and response traffic can carry a relay channel.
Why AI API C2 is harder to spot than classic C2
| Property | Classic C2 (own infrastructure) | AI service API C2 (AML.T0096) | What this means for detection |
|---|---|---|---|
| Destination reputation | New or rare domains, VPS ranges, dynamic DNS | Well-known AI provider domains with high reputation | Domain blocklists and threat intelligence feeds will not fire |
| TLS | Self-signed or odd certificates, unusual JA3/JA4 fingerprints from the implant | Valid provider certificates; client fingerprint depends on the HTTP library the implant uses | Fingerprint the client side, not the server |
| Timing | Regular beacons with jitter | Polling of stored objects, which can look like beaconing or like an app checking for a long-running job | Beaconing analytics still help, scoped by process |
| Authentication | Implant-specific tokens or none | A real provider API key belonging to the attacker's account | Key and tenant attribution becomes a detection point |
| Takedown | Sinkhole or seize the domain | Provider disables the key and account | Abuse reporting is part of containment |
The Cloud Services Abuse for C2 Guide covers the same economics for storage, chat and paste services. This page focuses on what is specific to AI providers: the growing number of sanctioned callers, the volume of legitimate traffic, and the API key as the attacker's identity.
Detection
No single signal is reliable. Combine three vantage points: the endpoint (which process opened the connection), the network edge (where the traffic went and how), and the AI access layer (whose key and which tenant).
| Signal | Telemetry source | What to look for | Tuning notes |
|---|---|---|---|
| Unexpected process calling AI endpoints | EDR network events joined to process creation | Developer utilities, signed system binaries, services or scheduled tasks connecting to AI provider domains | Build a baseline of sanctioned clients (browsers, approved desktop apps, gateway hosts, named workloads) per device group |
| Servers and non-user hosts reaching AI APIs | Firewall, proxy, cloud flow logs | Domain controllers, database servers or OT jump hosts with any AI provider traffic | On most server tiers the expected count is zero, so any hit is worth triage |
| Direct AI calls that bypass the gateway | Proxy and DNS logs | Resolutions of AI provider domains from hosts that should route through the AI gateway | Only works once a gateway or egress allowlist exists (see below) |
| Foreign API keys or tenants | AI gateway logs, TLS-inspecting proxy with header visibility | Requests authenticated with keys, organisation or project identifiers that are not yours | Needs a register of your organisation's AI accounts and keys; handle captured headers as secrets |
| Polling pattern to stored-object endpoints | Proxy logs with URL paths | Regular requests to object listing or retrieval endpoints (threads, messages, files) with little model inference traffic | Long-running legitimate jobs poll too; combine with the process signal |
| Loader behaviour | EDR | AppDomainManager injection, unusual .config files beside developer tools, unexpected files in temporary directories | Microsoft notes its injection alert may also fire on unrelated activity |
- Endpoint hunting: Microsoft's SesameOp post includes a Defender XDR hunting query that counts devices connecting to the AI API endpoint by initiating process. The same logic works in any EDR that records network connections with process context: group by process image and signer, then review rare combinations.
- Provider detections: Microsoft lists detections for the SesameOp loader and backdoor by name in its post; keep endpoint protection signatures current rather than relying on the AI traffic alone.
- AI usage telemetry: if you already run AI usage monitoring for governance, feed the same data to the SOC. See the AI Usage Monitoring Guide.
Prevention and hardening
ATLAS links AML.M0019 Control Access to AI Models and Data in Production to this technique, described as authenticating AI service API callers and monitoring queries for policy violations and misuse. For an enterprise that consumes AI services rather than hosting them, the practical form is egress and key governance. The following are NHI Mgmt Group recommendations.
- Inventory sanctioned AI callers. List which users, applications and workloads may call which AI providers, from which hosts. Shadow AI discovery feeds this list; see the Shadow AI Discovery Guide.
- Route AI traffic through one path. Send application and workload traffic through an AI gateway that holds the organisation's provider keys, and allow direct egress to AI provider domains only from that gateway and from managed browsers with web filtering. See the AI Gateway and LLM Gateway Guide.
- Deny AI egress from server tiers by default. Domain controllers, database and file servers, and OT-adjacent systems rarely need AI APIs. Make exceptions named and reviewed.
- Restrict to your own tenants where you can. Where your proxy, gateway or provider supports it, allow only requests that authenticate to your organisation's accounts. This turns an attacker's own key from invisible into blocked.
- Treat provider keys as non-human identities. Your own AI API keys should be stored in a secrets manager, scoped per project and rotated. An attacker who steals one of your keys can use your tenant as the relay, which defeats a foreign-key check. See the API Key Management Guide.
- Harden the endpoint stage. SesameOp still needed code execution and persistence. Microsoft's recommendations include tamper protection, EDR in block mode, cloud-delivered and real-time antivirus protection and auditing firewall and proxy settings.
Choosing controls by organisation size
- Small organisations: start with DNS or proxy logging of AI provider domains, a deny rule for servers, and EDR process context. A gateway may be more than you need; a short list of allowed AI apps is enough.
- Large organisations: deploy a gateway for application traffic, tenant restriction at the proxy, and SOC analytics that join EDR process data with proxy logs. Expect many sanctioned callers, so invest in the baseline.
- AI-heavy development teams: developer machines legitimately call many AI APIs from many tools. Scope the baseline by tool signer and keep developer keys in a vault rather than in environment files, so a foreign key stands out.
Where identity fits
In this technique the API key is the attacker's identity on the provider side and, if stolen from you, your identity used against you. Two identity controls make the difference: knowing every AI key and account the organisation owns (so foreign ones can be recognised), and issuing workload access through short-lived, gateway-brokered credentials rather than static keys copied to hosts. Leaked AI keys are also a common abuse pattern in their own right; see AI API key abuse and the Non-Human Identity (NHI) Guide.
Response
- Scope the host and process. Identify every device where the same process, file hash or .config pattern connected to an AI endpoint. Isolate affected hosts through EDR.
- Preserve evidence before clean-up. Keep proxy and DNS logs, EDR timelines, the implant and its configuration. The configuration may hold the attacker's API key and identifiers the provider needs.
- Block narrowly, then report. Block the process or host from AI egress rather than the whole provider domain, which would break sanctioned use. Report the key, account and indicators to the provider's abuse or security contact so the account can be disabled, as happened with SesameOp.
- Check your own keys. If any request used your organisation's keys, rotate them and review provider-side logs and stored objects for attacker use.
- Hunt for the rest of the intrusion. AI C2 is one stage. Look for the initial access, persistence and collection that preceded it, and for exfiltration over the same channel.
Detection and measurement
- Coverage: percentage of hosts whose AI egress is either routed through the gateway or explicitly allowlisted.
- Server tier exposure: number of server and infrastructure hosts with any AI provider traffic in the last 30 days (target zero outside named exceptions).
- Unknown callers: count of distinct process and signer pairs calling AI endpoints that are not on the sanctioned list, trended weekly.
- Key attribution: share of AI requests at the gateway or proxy attributable to a known organisational key or tenant.
- Triage time: median time from an unexpected-caller alert to a disposition.
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| MITRE ATLAS | AML.T0096 AI Service API; AML.TA0014 Command and Control; AML.CS0042 SesameOp | The technique and its case study |
| MITRE ATLAS mitigation | AML.M0019 Control Access to AI Models and Data in Production | Authenticate callers and monitor use for misuse |
| MITRE ATT&CK | T1102 Web Service; T1574.014 AppDomainManager; T1041 Exfiltration Over C2 Channel | The enterprise analogue, the SesameOp loading method and the likely exfiltration path |
| NIST SP 800-53 Rev. 5 | SC-7 Boundary Protection; AC-4 Information Flow Enforcement; SI-4 System Monitoring; IA-5 Authenticator Management | Egress control, monitoring and management of AI keys |
| NIST CSF 2.0 | PR.IR-01; DE.CM-01; DE.CM-09; PR.AA-01 | Network protection, network and endpoint monitoring, credential management |
Common failure patterns
- Allowlisting AI domains for everyone. Opening AI providers to all hosts to support adoption gives any implant a trusted channel. Allow by host group and caller.
- Watching domains, not processes. Proxy-only monitoring sees thousands of legitimate AI calls and cannot tell a browser from a backdoor. Join process context from EDR.
- No register of organisational keys. Without knowing your own tenants and keys you cannot recognise a foreign one, and you cannot tell whether a stolen key of yours is being used.
- Blocking the provider outright during response. A blanket block breaks business use and is often reversed within hours. Block the affected hosts and processes and report the account.
- Relying on content inspection. SesameOp encrypted its commands inside the API payload. Prompt or DLP inspection at the gateway will not reveal them; metadata and behaviour will.
Practitioner checklist
- Publish a list of sanctioned AI providers, clients and workloads, with the host groups allowed to call each.
- Route application and workload AI traffic through an AI gateway that holds the organisation's keys.
- Deny AI provider egress from server and infrastructure tiers by default, with named exceptions.
- Keep a register of every organisational AI account, project and key, stored in a secrets manager.
- Build an EDR analytic for rare process and signer pairs connecting to AI provider domains.
- Enable tenant or key restriction at the proxy or gateway where supported.
- Add AI provider abuse contacts to the incident response contact list.
- Include AI API C2 in purple team exercises using an organisation-owned test account.
Standards and references
- MITRE ATLAS: AI Service API (AML.T0096)
- MITRE ATLAS: SesameOp case study (AML.CS0042)
- MITRE ATLAS: Control Access to AI Models and Data in Production (AML.M0019)
- Microsoft Security: SesameOp, Novel Backdoor Uses OpenAI Assistants API for Command and Control
- MITRE ATT&CK: Web Service (T1102)
- MITRE ATT&CK: AppDomainManager (T1574.014)
- OpenAI: API Deprecations
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: MITRE ATLAS Guide · Beaconing and C2 Detection Guide · AI Gateway and LLM Gateway Guide · Cloud Services Abuse for C2 Guide