CLOSEDQUORUM: The Malware Asks Four Models What to Do Next, and Your Egress Logs Are the Evidence
Cisco Talos disclosed CLOSEDQUORUM on 22 September 2026, a Windows implant that hands its post compromise decisions to a vote between DeepSeek, Qwen, Mistral and Gemini. It is not confirmed in the wild and the sample ships with dummy keys. The lesson is still immediate: calls to AI provider APIs are now a command channel, and most organisations cannot say which of their processes make them.
Cisco Talos published its analysis of CLOSEDQUORUM on 22 September 2026, alongside an open source research toolkit called CAIRN built to hunt malware that integrates large language models. Talos describes CLOSEDQUORUM as the first publicly documented Windows implant to delegate its tactical command and control decisions to a panel of commercial models. There is no attacker operated server issuing instructions. Once it lands, the implant describes the machine it is sitting on, asks a set of hosted models what to do next, and acts on the answer.
The mechanics are specific enough to be worth reading closely. The binary is written in Go and runs to roughly 16.4 MB. It queries DeepSeek, Qwen, Mistral and Google Gemini in turn, passing a target description that includes hostname, operating system version, architecture and whether it has administrator rights. Each model must reply in a fixed JSON shape with one of four decisions: steal, inject, persist or move. The orchestrator takes a plurality vote, breaks ties in a fixed order with DeepSeek first and Gemini last, and if every model fails or refuses it falls back to a decision called consensus, which simply sleeps and tries again. The payloads behind those four words are ordinary: LSASS dumping, browser password and crypto wallet theft, Early Bird APC injection and process hollowing, and persistence through Run keys, scheduled tasks and WMI subscriptions. Stolen data is encrypted, chunked into 1,900 byte segments and posted to Discord webhooks.
The cold water belongs up front, because this story will be retold as autonomous AI hackers and it is not that. Talos has not confirmed any deployment in the wild. The distributed build contains placeholder values, a dummy API key and a dummy webhook URL, so the sample as found does nothing. The developer appears to compile a custom binary per customer with real keys injected at build time, which reads more like a product being prepared for carding forums, where Talos traced the author back to 2025, than like an active campaign. And the models are not doing anything clever. They are choosing between four prewritten capabilities that commodity stealers have shipped for years. What the vote buys the operator is resilience, since there is no single C2 server to seize and no single provider whose refusal stops the run.
That resilience point is the part defenders should sit with. Classic C2 detection leans on the fact that an implant has to talk to infrastructure the attacker controls, and that infrastructure is young, cheap and eventually blocklisted. CLOSEDQUORUM talks to api endpoints belonging to four large, reputable providers that many organisations have explicitly allowed through their proxies because staff and products use them every day. Domain blocking is not the answer, and Talos says so directly. The signal is behavioural: AI provider traffic originating from a Windows executable that has no business making it, similar requests sent to several providers within a short window, a Discord webhook from the same process, and activity repeating at randomised five to fifteen minute intervals.
Which exposes an inventory gap that has been building quietly all year. We have written repeatedly about shadow AI as a data leakage problem, staff pasting customer records into a chatbot or a coding agent sending source to a model nobody approved. CLOSEDQUORUM turns the same gap into a detection problem. If you cannot produce a list of which processes, services and hosts in your estate are expected to call OpenAI, Anthropic, Google, Mistral, DeepSeek or Qwen endpoints, then you have no baseline against which an unexpected caller stands out. Most organisations we speak to can name the approved tools in their AI register. Very few can map those tools to the executables and service accounts that actually generate the traffic, and fewer still alert when something outside that map starts talking.
There is a quieter credential angle as well. Each operator build carries live API keys for four providers, which means someone is paying for, or has stolen, those accounts. Provider abuse teams are part of the kill chain here, and your own keys are a target for exactly this kind of reuse. An organisation that leaves model provider keys in environment files, CI variables or developer laptops without rotation, spend alerts or per key usage review is offering free compute to the next person who builds one of these. We made the same point about AI credits as a unit of account last month: consumption you cannot attribute is consumption you cannot defend.
The framework mapping is direct and none of it is new. ISO 27001 covers this under network security, web filtering, monitoring activities and the management of secret authentication information, and the honest audit question is whether your monitoring baseline treats AI provider endpoints as a category at all. SOC 2 CC6.6 and CC7.2 ask how you restrict and monitor traffic at system boundaries and detect anomalies, and an auditor who has read the Talos write up will reasonably ask what would have fired. PCI DSS already requires outbound traffic from the cardholder data environment to be restricted to what is necessary, so any AI API traffic leaving that segment should be explicitly justified or blocked. ISO 42001 is less central, but its AI system inventory is the natural place to record which components are allowed to call which models, and our ISO 42001 and compliance readiness guides treat that inventory as the foundation it should be.
The work is short. Pull a week of proxy, DNS or firewall logs and list every internal source that reached an AI provider API, then reconcile that list against your AI register and your policy templates for acceptable use. Anything you cannot explain is either shadow AI or something worse, and both deserve a ticket. Add a detection for a single process contacting several model providers within minutes, and for AI API traffic from hosts that have no approved AI workload. Put spend alerts and rotation on every provider key you own. If you run an EDR, test whether it correlates AI API traffic with LSASS access or new WMI subscriptions from the same process, because that correlation is the one Talos highlights and the one no domain list will give you.
Our read is that CLOSEDQUORUM matters less as a working weapon than as a design pattern that is now public, documented and easy to copy. Moving decision making to reputable cloud APIs removes the attacker infrastructure defenders have spent twenty years learning to find. The organisations best placed for that shift are the ones that already treat LLM traffic as a monitored, inventoried egress category with an owner, rather than a line on an allow list that was added to stop the helpdesk tickets. If your AI governance programme currently stops at an approved tools list, this is the week to connect it to your network telemetry.
Editorial note: AES Tech reviews are independent. Some outbound links are affiliate links and are marked sponsored; they never change our rankings. See our disclosure.
Get the next post by email
One short email when something worth knowing ships. No spam, unsubscribe anytime.
Comments
Moderation policyLoading comments...
Add a comment
Corrections and first-hand experience are the most useful things you can leave. Comments are screened automatically and reviewed by a human; see the moderation policy.