The cybersecurity industry has spent the last two years discussing AI-assisted attackers, AI-generated malware and the potential for autonomous agents to change offensive operations.
CLOSEDQUORUM is interesting because it moves that discussion from theory into malware architecture.
Cisco Talos recently analyzed a Windows implant that uses multiple commercial LLM providers to influence its next tactical action. The public sample is not confirmed as part of an active campaign, but its design provides a useful look at how an LLM-driven malware control loop could work.
The architecture
At the center of the sample is a component Talos identifies as the ModelOrchestrator.
Rather than receiving every instruction from a conventional C2 server, the implant queries several models.
The reported providers are:
DeepSeek
Qwen
Mistral
Gemini
The models are prompted to behave as malware strategists, but their responses are constrained to a structured decision format.
This is an important implementation detail.
The models are not simply generating arbitrary shell commands that the malware executes directly.
Instead, the implant defines a limited set of possible capabilities. The model selects among those options, and the corresponding handler executes the action.
That creates a much more constrained and auditable decision architecture.
Voting instead of trusting one model
The malware does not appear to rely on a single model.
The providers are queried one by one and their decisions are combined through plurality voting.
A tie is resolved through a fixed provider order.
This is an interesting engineering choice.
From an attacker perspective, depending on one API introduces obvious reliability problems. The provider may be unavailable, rate-limit the request or refuse the prompt.
A multi-model design provides another layer of resilience.
The failure mode is also relatively conservative: when the models fail to provide a usable decision, the implant falls back to a non-operative state.
Why conventional C2 detection becomes harder
Traditional C2 detection often looks for infrastructure controlled by an adversary.
A suspicious domain.
A suspicious IP.
A custom protocol.
A recognizable beacon.
CLOSEDQUORUM changes that equation.
The implant can potentially communicate with infrastructure operated by legitimate commercial AI companies.
That does not make the traffic inherently suspicious.
Millions of legitimate systems can call AI APIs.
The defensive opportunity therefore lies in correlation.
Consider an executable that:
contacts several AI providers;
communicates with a Discord webhook;
accesses LSASS;
performs process injection; and
repeatedly reappears at irregular intervals.
Each signal has legitimate explanations.
Their combination is much harder to explain as routine application behavior.
The CAIRN response
Talos released CAIRN alongside the CLOSEDQUORUM research.
CAIRN is designed to identify AI-integrated malware through what Talos calls “cognitive artifacts.”
These can include:
prompt templates
model-provider endpoints
API-key prefixes
jailbreak-related terminology
tool-calling structures
The interesting part is that CAIRN starts from metadata rather than immediately executing suspicious binaries.
That makes the approach potentially useful for large-scale hunting.
There is a trade-off, however.
AI-related strings are not automatically malicious.
Legitimate applications can contain model names and API endpoints. Packaged binaries can also introduce substantial noise.
Metadata can narrow the search.
Reverse engineering still provides the final validation.
The biggest caveat
One detail should remain front and center when discussing CLOSEDQUORUM.
Talos did not observe a complete end-to-end execution of the public build.
The sample contains placeholder API credentials and a dummy webhook.
There is therefore no confirmed evidence that this exact sample represents an operational campaign in the wild.
That means the significance of CLOSEDQUORUM is currently architectural rather than epidemiological.
We are not looking at evidence that autonomous LLM-driven malware has suddenly become widespread.
We are looking at a concrete implementation showing how such a model-driven control mechanism could be built.
Why this matters for defenders
The traditional distinction between malware and AI software is becoming less useful.
A malicious executable can already use cloud APIs, encrypted channels, commercial infrastructure and third-party services.
The addition of an LLM creates another abstraction layer.
The endpoint may no longer receive an explicit command such as “execute capability X.”
Instead, the endpoint may receive context, ask one or more models for a decision, vote on the result and then execute a locally implemented capability.
From a detection perspective, that means the question becomes:
Which process is asking the model to make tactical decisions, and what does that process do immediately before and after the request?
That is potentially much more valuable than simply blocking AI domains.
CLOSEDQUORUM is still an early example, but it illustrates why AI security is increasingly becoming an endpoint-security problem as much as a model-security problem.
Top comments (0)