Malware no longer needs its own server address in your proxy logs: it can ask a public AI assistant to fetch the attacker's page and read the reply. MITRE ATLAS tracks this as AML.T0114 AI Service Web Interface, in the Command and Control tactic (AML.TA0014), with maturity rated as demonstrated. ATLAS describes malware that opens or automates a browser, embedded browser or WebView component, prompts a public AI assistant to fetch an attacker-controlled URL with victim data in the parameters or prompt, and then parses the assistant's answer for instructions. This guide is for SOC, detection engineering and AI governance teams who need to spot that pattern and reduce the room for it. General cloud-service C2 is covered in the Cloud Services Abuse for C2 Guide, and the API-key variant of the same idea is AML.T0096 AI Service API; this page covers the web interface angle only.
Key takeaways
- The AI service is the proxy. The implant talks only to a trusted AI domain; the AI service makes the request to the attacker's site and carries the answer back.
- There may be no credential to revoke. ATLAS notes the technique suits AI web interfaces that allow anonymous browsing, summarisation or URL fetch, which sidesteps controls built on API keys, accounts and tokens.
- Detection moves to the endpoint and the prompt. ATLAS says the pattern shifts detection toward browser automation, prompt content, URL-fetch behaviour and AI service telemetry.
- It is proven, not theoretical. ATLAS case study AML.CS0061 records Check Point Research building a working relay through two public assistants in February 2026.
- Enterprise AI policy is a C2 control. Knowing which AI services are sanctioned, which require sign-in and which processes may call them turns an invisible channel into an anomaly.
How the relay works
The mechanics matter only to the depth defenders need. ATLAS and the Check Point research describe a loop with four parts:
- Session: the implant starts a web session with a public AI assistant, often anonymously, using an embedded browser rather than raw HTTP requests so that the traffic looks like a person using a chat page. Check Point used the Microsoft WebView2 control, which it notes is preinstalled on Windows 11.
- Outbound data: the prompt asks the assistant to fetch and summarise an HTTPS page on an attacker-registered domain, with host information appended to the URL query string. Check Point reports that encoding the data helped it pass the services' safety filters.
- Inbound tasking: the attacker's page returns content that the assistant reproduces in its answer, and the implant parses that answer as its next command.
- Repeat: each cycle is an ordinary looking chat exchange with a well-known AI domain.
The attacker's server is contacted by the AI provider's infrastructure, not by the victim, so the victim network never resolves or connects to the attacker domain. That is the property that makes this different from the cloud-service C2 patterns already in ATT&CK, such as T1102.002 Bidirectional Communication, where the implant itself reads and writes to the third-party service, or T1090.002 External Proxy.
Web interface versus API
| Aspect | AML.T0114 AI Service Web Interface | AML.T0096 AI Service API |
|---|---|---|
| Access path | Browser, embedded browser or WebView driving the consumer chat page | Programmatic calls to the provider API |
| Credential | Often none, where anonymous use and URL fetch are allowed | API key or token, which can be found and revoked |
| Who contacts the attacker | The AI service, through its browsing or URL-fetch feature | Usually the implant, with the API used to store or relay messages |
| Best detection layer | Endpoint process lineage, web proxy and AI usage telemetry | Key inventory, provider usage logs, egress to API endpoints |
| Kill switch | Block or restrict the service, or require sign-in | Revoke the key, suspend the account |
Case study: AI in the Middle (AML.CS0061)
Check Point Research published "AI in the Middle" on 17 February 2026, and ATLAS recorded it as exercise AML.CS0061. The researchers looked for public AI assistants that could fetch arbitrary attacker-controlled URLs without API credentials, and found that Grok and Microsoft Copilot met their conditions at the time. Their proof of concept, a small program hosting WebView2, sent basic host reconnaissance out in a URL parameter and received commands back in the assistant's response. ATLAS maps the earlier step of finding suitable services to AML.T0095 Search Open Websites/Domains and the data leaving through the fetched URL to AML.T0086 Exfiltration via AI Agent Tool Invocation.
Three findings from the research matter for defenders:
- No kill switch: because no account or key was involved, the usual response of suspending an account or rotating a key did not apply.
- Some service-side limits existed: the researchers report restrictions such as no direct IP or plain HTTP targets, which they met by registering an HTTPS domain. Provider controls raise the cost but do not close the channel on their own.
- Shared responsibility: Check Point describes this as a service-abuse class of issue rather than a memory corruption bug, and recommends that AI providers authenticate and give enterprises control over web-fetch features, while defenders treat AI domains as high-value egress points. The researchers state they disclosed the findings to the Microsoft and xAI security teams.
What to detect and where
ATLAS maps one mitigation to this technique: AML.M0024 AI Telemetry Logging and Monitoring, noting it can help detect suspicious prompts, browser-based AI service interactions, URL-fetch requests and AI responses used to relay command-and-control data. Enterprises rarely see the provider side, so most of the work is on the endpoint and the network edge.
| Signal | Why it matters | Data source |
|---|---|---|
| A process that is not a browser, and not a known business application, hosting an embedded browser that reaches AI assistant domains | The implant needs a browser engine to drive the chat page | EDR process and module telemetry, network connections by process |
| WebView2 browser processes tied to an unfamiliar user data folder or launched by an unsigned or newly seen binary | Microsoft documents that each WebView2 process group is bound to one user data folder, which helps tie activity to its host application | EDR command-line and parent process fields |
| Regular, timed sessions to an AI assistant from a host with nobody logged on, or outside working hours | C2 polling has a rhythm human chat does not | Proxy or SWG logs, beacon analytics |
| Anonymous sessions to consumer AI services from managed devices where sign-in is policy | The technique favours unauthenticated use | SWG, CASB or AI usage monitoring |
| Prompts that ask the assistant to fetch a URL with long encoded query strings, and responses that contain encoded blobs | The outbound and inbound halves of the relay | Enterprise AI gateway or browser extension prompt logging, where deployed |
| Newly registered domains appearing in prompt text on enterprise AI tenants | Attacker infrastructure is named in the prompt, not in DNS | AI usage logs joined with domain reputation |
Beacon analysis techniques transfer directly: see the Beaconing and C2 Detection Guide. The difference is that the destination is a legitimate, high-volume domain, so baselining by process and by user is more useful than by destination.
Mitigations and controls
- Sanction a short list of AI services: allow the enterprise AI assistants you have contracted for and block or isolate consumer and anonymous AI chat services at the secure web gateway. See the AI Usage Monitoring Guide.
- Require identity on AI use: where an assistant is allowed, require corporate sign-in so that every session has a user, and so that anonymous sessions from managed devices stand out. This restores the kill switch the technique tries to remove.
- Restrict browsing features where you control them: on enterprise tenants, review whether web grounding or URL fetch is needed for each user group, and log it where the platform allows. Check Point's recommendation to providers is enterprise control and visibility over which external URLs models access.
- Control what can run a browser engine: application control that limits unsigned or unknown executables also limits which processes can host an embedded browser. See the Enterprise Browser and Browser Security Guide.
- Route AI traffic through one inspection point: an AI gateway or SWG with prompt logging gives the telemetry AML.M0024 relies on. See the AI Gateway and LLM Gateway Guide.
- Servers and agents get no consumer AI egress: build servers, AI agents and other workloads should reach only the AI endpoints their identity is approved for, through an egress allowlist. See the Agent Egress Control and Network Isolation Guide.
Choosing controls by organisation size
| Situation | Practical starting point | Trade-off |
|---|---|---|
| Small organisation, no AI gateway | SWG category block on unsanctioned AI chat, one sanctioned assistant with sign-in, EDR hunt for non-browser processes contacting AI domains | Users lose ad hoc access to other assistants |
| Mid-size, sanctioned AI with SSO | Tenant-only access, alert on anonymous sessions from managed devices, process lineage rules | Requires maintaining an allowlist of applications that legitimately embed AI chat |
| Large or regulated, AI gateway in place | Prompt and response logging, URL-in-prompt analytics, per-group restrictions on web grounding | Prompt logs hold sensitive data and need their own access controls and retention |
How to test
- Inventory first: list which AI assistant domains your proxy sees, from which processes, and whether sessions are authenticated.
- Emulate safely: in a lab, have an authorised red team drive an AI assistant from a non-browser process to fetch a test page you own, with benign marker data in the URL. No real tasking is needed to test detection.
- Check each layer: confirm whether EDR flags the process lineage, the SWG blocks or logs the session, and AI usage logging captures the prompt.
- Tune and roll out: run new rules in alert-only mode for two weeks against the baseline, then enforce blocks for unsanctioned services. Keep a documented exception path and roll back a block by removing the category rule if a business process breaks.
- Repeat: add the scenario to AI red team scope (AML.M0035 AI Red Team) and rerun after any AI platform or proxy change.
Metrics
- Authenticated share: percentage of AI assistant sessions from managed devices tied to a corporate identity.
- Unsanctioned AI sessions: weekly count of sessions to AI services outside the approved list, trending down.
- Process coverage: share of AI domain connections attributed to a known browser or approved application.
- Emulation detection rate: proportion of red team relay tests detected, and time to alert.
Common failure patterns
- Allowlisting AI domains wholesale: treating every AI domain as trusted business traffic gives the relay a free pass.
- Relying on key revocation: incident runbooks that end with "rotate the API key" have nothing to rotate here.
- Watching destinations, not processes: network-only analytics see a popular domain and move on.
- Anonymous access left open on managed devices: the one condition the research needed.
- Prompt logs nobody reads: collecting AI telemetry without detections for URLs and encoded content in prompts.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATLAS | AML.T0114 in AML.TA0014; case study AML.CS0061; mitigation AML.M0024 | The technique, its demonstration and its mapped mitigation |
| MITRE ATT&CK | T1102 Web Service (T1102.002 Bidirectional Communication); T1090.002 External Proxy; T1071.001 Web Protocols | Closest enterprise analogues for the channel |
| NIST SP 800-53 Rev. 5 | SC-7 Boundary Protection; AC-4 Information Flow Enforcement; SI-4 System Monitoring; AU-12 Audit Record Generation | Egress control, approved flows, monitoring and logging |
| NIST CSF 2.0 | DE.CM-01; DE.CM-09; PR.IR-01 | Network and runtime monitoring, protection from unauthorised use |
The related ATLAS techniques AML.T0096 AI Service API (API-based relay) and AML.T0120 AI Artifact Repository (repositories as dead drops) cover neighbouring C2 channels. The tactic overview is the ATLAS Command and Control Tactic.
Practitioner checklist
- Publish a list of sanctioned AI assistants and block or isolate the rest at the web gateway.
- Require corporate sign-in for every allowed assistant on managed devices.
- Alert on anonymous AI assistant sessions from managed devices.
- Hunt for non-browser processes hosting an embedded browser that reaches AI domains.
- Log prompts and responses for enterprise AI use and detect URLs with encoded parameters.
- Deny consumer AI egress from servers, build systems and AI agents.
- Add AI relay C2 to incident runbooks, with blocking and containment steps that do not depend on keys.
- Emulate the relay in a lab at least once a year and after AI platform changes.
Standards and references
- MITRE ATLAS: AI Service Web Interface
- MITRE ATLAS: AI in the Middle: Web-Based AI Services as C2 Relays
- MITRE ATLAS: AI Telemetry Logging and Monitoring
- Check Point Research: AI in the Middle: Turning Web-Based AI Services into C2 Proxies
- MITRE ATT&CK: T1102 Web Service
- MITRE ATT&CK: T1090.002 External Proxy
- Microsoft Learn: Process model for WebView2 apps
Related NHI Mgmt Group resources: Cloud Services Abuse for C2 Guide · Command and Control (C2) Guide · AI Usage Monitoring Guide · MITRE ATLAS Guide