> ## Content Index
> Fetch the complete content index at: https://www.dailyferment.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# CLOSEDQUORUM: the malware that puts its next move to a vote
- URL: https://www.dailyferment.com/closedquorum-ai-malware-four-model-vote/
- Published: 2026-09-23T16:00:00.000Z
- Updated: 2026-09-23T16:00:09.000Z
- Description: Cisco Talos pulled apart a 16.4MB Windows binary that polls four commercial language models and acts on the majority vote. The mechanism is clever. The defensive problem it creates is worse than the mechanism.
- Author: Rana Bilal Zafar
- Tags: Security, AI, Engineering, #built-and-broken

The file is 16.4 megabytes. That's fat for a Windows executable and completely unremarkable for one written in Go, so the size on its own tells you nothing. Pull it apart and the bulk turns out not to be the payload. It's four API clients.

Cisco Talos published the teardown on Tuesday morning. The malware is called CLOSEDQUORUM, and the thing it does that no publicly documented sample has done before is this: before it acts on a machine it has already infected, it asks four commercial language models what to do next, and it does whatever the majority says.

Researcher Ryan Fetterman found it using CAIRN, the Cognitive Artifact Intelligence Research Network, an open-source toolkit Talos built to hunt for malware with AI plumbing wired into it. One thing before we go further, because it changes how you should read everything below. The sample does not work. Talos says so plainly in the report, and we will come back to why that matters more than it sounds.

![Source code on a computer monitor in a darkened room](https://storage.ghost.io/c/d7/b7/d7b77195-48c5-45ab-8688-51750879d1d6/content/images/2026/09/df9-code.jpg)

The decision logic sits in plain code inside a 16.4MB Go binary. The novelty is not how it is written, it is who it asks. Photo: Unsplash

## How CLOSEDQUORUM decides what to do next

Every cycle, the implant describes the machine it is sitting on. It assembles a short context string labelled TARGET carrying the hostname, the OS architecture, the CPU count, the Windows version, whether it's running with admin rights, and the process it currently has its eye on. That last field refreshes each round, so the models are answering a question about a situation that moves rather than a fixed snapshot.

That string goes to DeepSeek first, then Qwen, then Mistral, then Google Gemini. Each one replies inside a fixed JSON schema, and the field that matters holds one of four words.

**steal** fires credential dumping, browser password extraction and crypto wallet harvesting simultaneously. **inject** generates shellcode and then branches into either process hollowing or an APC injection path depending on a second field in the response. **persist** establishes persistence. **move** is lateral movement, and in the build Talos examined there is no handler for it at all. A model can vote for it. Nothing happens.

Four answers come back and the most common one wins. When the vote splits evenly, DeepSeek gets the casting vote. If DeepSeek failed or refused, it falls to Qwen, then Mistral, then Gemini.

One decision cycle

CLOSEDQUORUM asks four providers, then counts the ballots

TARGET: hostname, arch, CPUs, Windows version, admin, current process

↓

**1\. DeepSeek**casting vote on a tie

**2\. Qwen**second in the order

**3\. Mistral**third in the order

**4\. Gemini**last in the order

↓

Plurality wins → steal | inject | persist | move

Each provider replies inside a fixed JSON schema, so the answer is always one of four words. A refusal or a timeout does not stop the cycle, it just removes one ballot. Source: Cisco Talos, 22 September 2026.

## Why CLOSEDQUORUM asks four models instead of one

The obvious reading is that four opinions produce a better decision than one. That's almost certainly not what the author was buying.

The most common way this kind of abuse fails is that the model says no. Ask a single provider what to do with a set of freshly dumped credentials and you're one refusal away from a dead session. Ask four and count the votes, and a refusal stops being a failure. It becomes a spoiled ballot. You no longer need any particular model to cooperate. You need two of four to land on the same word. I cannot claim that reading. Talos frames the vote as redundancy for when a provider refuses, times out or returns malformed output, and [the trade coverage picked it up the same way](https://runtimewire.com/article/cisco-talos-cairn-closedquorum-ai-malware?ref=dailyferment.com). What I would add is the size of the gap it closes. You go from needing one model to cooperate to needing two of four to land on the same word.

The second reason is duller and probably mattered more. Rate limits exist. Outages happen. Keys get revoked, especially keys bought under a name that won't survive a fraud review. Spreading the dependency across four providers means no single one of them can switch the implant off. That's the same resilience argument a payments company makes when it refuses to route through one liquidity provider, which we looked at from the buyer's side [in our piece on stablecoin FX routing](https://www.dailyferment.com/stablecoin-fx-routing-cost-provider-churn/). The logic is identical. It's just running in the other direction.

I first read the tie-break order as a tell. It is not alphabetical and it is not the order the providers launched in, so it looked like somebody had sat down and ranked which model they trusted most. The duller explanation is probably the right one. [One analysis](https://cyberwarrior76.substack.com/p/the-quorum-is-not-the-story) points out that a fixed check order falls out of the order four string constants happen to be declared in, with nobody deciding anything. I am flagging my own first reading because this is exactly the kind of detail that gets narrated into intent.

![An open plan office with people working at desks and monitors](https://storage.ghost.io/c/d7/b7/d7b77195-48c5-45ab-8688-51750879d1d6/content/images/2026/09/df9-office.jpg)

The awkward part for defenders is that the implant talks to the same AI endpoints the developers at the next desk already use. Photo: Unsplash

## The problem CLOSEDQUORUM creates for defenders

The standard answer to a command and control implant is to cut the channel. You find the domain, you sinkhole it, you block it at the egress gateway, and the thing goes quiet. That answer doesn't survive contact with this design.

The channel here is DeepSeek's API, Alibaba's, Mistral's and Google's. Those are endpoints your own engineers reach for several times an hour. Block them and you break tooling the company is paying for. Leave them open and the implant keeps voting. Most security teams have never had to argue that particular trade-off, because until now the malicious domain and the useful domain were never the same domain.

There is a decent argument that this cuts the other way. [The same analysis](https://cyberwarrior76.substack.com/p/the-quorum-is-not-the-story) reads the four providers plus the Discord webhook as five chokepoints the attacker does not control, where keys get revoked, requests get rate limited, prompts get refused and traffic gets logged and correlated, and concludes the trade currently favours the defender. I think that is right, and it does not help the person running the egress gateway. The provider can act. The enterprise, against this design, mostly cannot. Those are two different defences with two different owners, and only one of them is yours.

It also degrades in the wrong direction. Cut one provider of four and three remain, and a plurality still resolves. Cut two and the tie-break order quietly takes over and the implant carries on with a smaller electorate. You would have to sever all four to silence it, and at that point you have also severed the AI tools your engineering org now treats as infrastructure.

What is actually distinguishable is the shape of the traffic rather than where it goes. A host sending a compact structured description of itself on a loop, to four different AI providers, and getting back short JSON constrained to a handful of enum values, doesn't look like a developer using a chat API. The cadence is regular, the payload is small and near identical each time, and the response is machine narrow. That is a content signature, not a destination signature, and it's the one worth building. This is where Talos and the coverage land too, on behavioural detection rather than blocklists: a process polling several AI services while it touches LSASS and calls a Discord webhook.

## What Talos did not find in CLOSEDQUORUM

Coverage of a report like this tends to bury the caveats near the bottom. They belong up here.

The build Talos analysed cannot run. The API keys in it are placeholders, literally a dummy value where the credential should be. The Discord webhook it reports to is a dummy too. The researchers didn't observe the sample executing end to end, and there is no confirmation that it has been deployed against anybody. Artifacts left in the binary link the developer to postings on a carding forum going back to 2025, which tells you something about who built it and nothing at all about whether it has ever been used.

So what Talos published is not an incident report. It's a design that someone shipped before it was finished, and that's a stranger thing to read. Normally the industry learns how an attacker thinks by reconstructing it backwards from damage. Here the reasoning is sitting in the open, complete, with the keys left blank like a form waiting to be filled in.

## What to do about it this week

Nothing here needs a project. It needs a few answers written down somewhere findable. Which AI provider domains your organisation actually uses, and from which hosts. Whether your egress logging keeps the shape of those requests or only where they went. What you say the first time an incident channel reaches block the C2 and somebody replies that the C2 is Gemini.

That last one is a policy question, not a technical one, and it's much easier to settle on a quiet Wednesday than at two in the morning.

## Confidence

High on the mechanics: the provider order, the voting rule, the tie-break sequence, the four decision values and the missing lateral movement handler all come straight from the [Talos report published on 22 September 2026](https://blog.talosintelligence.com/the-closed-quorum-inside-the-first-reported-autonomous-ai-c2-implant/?ref=dailyferment.com), written by Ryan Fetterman. High on the limitations, for the same reason. Lower on the reading of intent. Nobody has interviewed the author of this thing, so the argument that the quorum exists to route around refusals is inference from the design, not something anyone has confirmed. Treat it as the most economical explanation rather than a finding. Commentary appeared within hours and I have now read the main pieces, which cost this article two claims. The refusal redundancy reading and the preference for behavioural detection over blocklists are both already in the Talos report and the trade coverage. The counter that the four providers are chokepoints the attacker does not control belongs to the Cyber News Network piece linked above. What is left as mine is narrow: that provider-side leverage and enterprise-side leverage are different defences with different owners, and that the blocking decision is a policy call somebody should settle before the incident rather than during it.

Zero working samples of this have been seen by anyone. That is the number I would keep an eye on, and not because the thing is hard to build. The design is done. It sits in a public report now with the credential fields left blank, and four API keys is not a difficult shopping list.