CLOSEDQUORUM Asks Four Model Providers What To Do Next, and Takes the Majority Answer
Cisco Talos disclosed CLOSEDQUORUM on September 22, 2026: a 16.4MB Go implant for Windows that sends host information to DeepSeek, Qwen, Mistral and Google Gemini, then executes whichever action wins a plurality vote. Talos has not confirmed a real-world victim. This article works through what the architecture implies for egress visibility on commercial model APIs.

Cisco Talos published its analysis of CLOSEDQUORUM on September 22, 2026. The implant is a 16.4MB, 64-bit Windows executable compiled in Go, and the interesting part is not the payload menu but the control flow. It collects host information, sends a structured request to four commercial model providers, and aggregates the answers by plurality vote on a Decision field before executing whatever wins. DeepSeek holds tiebreaker priority, then Qwen, then Mistral, then Gemini. That voting architecture is what makes this closedquorum ai malware sample worth reading carefully, even though Talos has confirmed no victim anywhere.
I want to be precise about what this sample is and what it is not, because the reporting around it has been looser than the research, and then work through the one defensive conclusion that actually follows.
TL;DR
- CLOSEDQUORUM queries DeepSeek, Qwen, Mistral and Google Gemini, then executes the action that wins a plurality vote, with DeepSeek breaking ties.
- Its action menu holds four entries:
steal,inject,persistandmove, andmovehas no handler in the distributed build. - The public build is non-functional. Every model credential initialises to
dummy_api_keyand the Discord webhook todummy_webhook_url, so what circulated is a working template and not a deployed weapon. - The defensive read is narrow: an enterprise that forces all outbound model-API traffic through an identity-aware policy point turns an unattributable process calling Gemini into a visible egress event.
What Talos actually found
Cisco Talos describes the implant as the first reported case of a C2 loop delegating its decisions to a model quorum. Rather than hardcoding the next move, the binary gathers host context, builds a request, and asks four providers what to do.
The action set holds four entries. steal covers credential and wallet theft, inject covers process injection, persist handles persistence, and move has no handler at all in the build that circulated. A menu with a dead entry tells you the developer was working toward lateral movement and had not finished.
Two facts constrain every claim anyone makes about this sample. Talos states plainly that it has no confirmation of in-the-wild deployment. And the distributed binary is non-functional: every LLM API credential initialises to the literal string dummy_api_key, and the Discord webhook initialises to dummy_webhook_url. BleepingComputer and Security Affairs both picked up the research on September 22 and 23.
Separately from the implant's behaviour, Talos connected artifacts in the binary to postings on criminal carding forums dating back to 2025. That is an attribution finding about a person, and it says nothing about whether the code ever ran against a victim. Keeping those two findings apart is the difference between reporting research and amplifying it.
Why the voting design matters more than the payloads
Credential theft and process injection have been in commodity malware for twenty years. The novelty sits one layer up.
A hardcoded implant is a fixed target. Its logic is in the binary, so a detection engineer can read the branches and write a signature for the behaviour. Moving the decision to an external model API means the logic is no longer in the file. The binary holds a menu and a request format; the reasoning happens somewhere else, on infrastructure the defender cannot inspect, and it can change between two runs of the same sample without a single byte changing on disk.
My honest opinion is that the four-provider quorum is over-engineered for an attacker and that a single API call would have worked nearly as well. The design reads like someone solving for reliability against provider refusals and rate limits, which is a mundane engineering motive, and that mundanity is the part that should concern people. This is what it looks like when model APIs become ordinary infrastructure for the people building offensive tools.
The request the loop builds carries host context and a privilege level, and each provider answers with a value in the Decision field. Four answers come back, several of them disagree, and the plurality winner executes. On a tie, DeepSeek's answer governs, then Qwen's, then Mistral's, then Gemini's. Two providers voting for credential theft while a third asks for process injection and a fourth asks for persistence still produces a theft, and the sample's own tiebreak ordering means DeepSeek effectively holds a casting vote in the close cases.
Where this sits outside the gateway boundary
I want to be blunt about scope, because the marketing version of this story writes itself and it would be wrong.
CLOSEDQUORUM runs as an attacker-controlled process on a host the attacker has already compromised. Its calls go to public commercial APIs using the attacker's own keys. No policy gateway operated by the victim sits on that path, and no proxy stops malware that is already executing locally. DeepInspect does not defend the endpoint, and any claim that it blocks this implant would be false.
That leaves one honest defensive argument, and it is about visibility.
The egress-visibility argument
An enterprise that requires every outbound call to a model provider to pass through an identity-aware policy point gains a specific property: calls to DeepSeek, Qwen, Mistral and Gemini that carry no attributable employee or service identity become anomalies at the point of egress instead of ordinary-looking HTTPS traffic.
Consider a workstation inside a company that already routes sanctioned agent traffic through a gateway. A process on that host opens a connection to a provider endpoint without a resolvable identity behind it. In a default network, that request is TLS to a reputable hostname, sitting in the same flow logs as a hundred legitimate calls to the same provider. Behind an enforcement point that requires identity per request, the same request has no identity to present, and the refusal itself becomes a record.
The property that produces this is exhaustiveness. A gateway covering eighty percent of model traffic leaves an unmonitored path, and unattributable traffic looks exactly like the traffic on the uncovered path. The control only works when it covers everything, a point I made in more depth in AI egress control. Binding requests to a resolved identity is the mechanism underneath it, covered in AI agent identity.
How this differs from the confirmed campaigns
Two shipped pieces cover adjacent ground, and the distinctions are substantive.
The JadePuffer case was a fully autonomous ransomware kill chain with confirmed damage, written up in the first agentic ransomware attack chain. An earlier campaign used a real deployed open model as the reasoning engine behind an active intrusion effort. Both of those had victims.
CLOSEDQUORUM has none. Its distinguishing property is the architecture: a decision loop that outsources judgment to a quorum of commercial providers and degrades gracefully when one refuses. Treat it as a design document that leaked rather than an incident, and track whether a functional build appears with real keys. The running thread sits in agentic AI news.
DeepInspect
DeepInspect is a stateless proxy between authenticated users or agents and any LLM endpoint. Every request is evaluated inline against the identity behind it, the classification of its content, the destination model and the policy in force, and the decision is written before the response returns.
For the class of problem this sample points at, the useful property is coverage of the egress path. Traffic from a registered agent presents a resolved identity and passes. Traffic from an unregistered process has no identity to present, so the policy decision is a refusal and the refusal is recorded with its source. The boundary is authenticated HTTP traffic between your people or agents and the models they call. Endpoint protection, malware removal and host forensics stay with the tools that own them, and nothing here stops an implant already running on a laptop.
If you cannot currently name every process in your environment that is allowed to call a model API, that inventory is the first piece of work. Book a demo today.
Frequently asked questions
- Is CLOSEDQUORUM being used in attacks right now?
Talos has no confirmation of in-the-wild deployment, and the build that circulated cannot run because its credentials are placeholder strings. Anyone describing this as an active campaign is going beyond the research.
- Do the model providers bear responsibility here?
The providers are being called by an attacker's own account, with the attacker's own keys, for text generation that looks like systems-administration questions. Abuse detection on the provider side is a real discipline and a separate one. A deployer cannot wait on it.
- Would blocking these four providers at the firewall solve it?
Blocking by hostname moves the problem. An implant designed around provider substitution will use whichever endpoint answers, including a self-hosted one. Requiring an identity on every outbound model call holds regardless of which provider is on the other end.
- What is the actual detection signal?
An outbound model-API request that no authenticated user or registered service can be tied to. That signal only exists if something on the egress path demands identity per request and records the absence of one.