New malware puts its next move to a vote among four AI models

On 22 September 2026 Cisco Talos published its analysis of CLOSEDQUORUM, a Windows implant that hands the choice of its next action to four commercial AI models. The binary is written in Go, measures 16.4 MB, and queries DeepSeek, Qwen, Mistral and Google Gemini in turn about what to do. Their answers are tallied, and the action with the most votes is carried out. Talos has not confirmed that the implant has been used in attacks. Artefacts from the file do, however, link its developer to carding posts on criminal forums going back to 2025.

The models are not free to answer as they please. Talos recovered the system prompt from the binary, and it tells the model to provide only executable decisions. The reply then has to fit a fixed JSON schema with four actions: steal, inject, persist or move on. The last of those has no code behind it in the build that was distributed publicly. When the vote lands on stealing, the implant dumps LSASS memory while also collecting saved passwords from Chrome, Edge and Firefox and wallets from MetaMask, Exodus and Ethereum. What it takes is encrypted with AES-256-GCM, split into 1900 byte segments and posted to a Discord channel the attacker controls. That same channel receives, in real time, the reasoning behind the decision that won, with the model and the timestamp given in the same message.

Ties are settled by an order of precedence fixed in advance, with DeepSeek ahead of Qwen, Mistral and Gemini. If every model fails to answer, the implant sleeps and tries again rather than falling back on a default action. The publicly distributed file carries placeholders where the API keys and the Discord address should be, so it does not work as it stands. Build artefacts Talos found, spanning seven days of development, suggest that each operator receives an individual binary with keys and channel injected at compile time. Talos stresses that its account of the voting loop rests on static analysis of the binary, and that it did not observe the architecture running end to end.

What this means for you if you build the detections

What disappears in this architecture is the server you are used to hunting for. No dedicated command and control server can be blocked, and no new server surfaces in the certificate transparency logs. The exfiltration channel is still there, since each operator has a Discord webhook of their own. What you see instead is traffic to model providers that thousands of legitimate applications talk to every day. Talos says it plainly: domain blocking is of little use here, and it is the combination of behaviours that stands out. If you have no inventory of which programs on your machines have a real reason to reach a model provider, that inventory is what you need first.

Our assessment is that this deserves attention even though the file in circulation does not run. The architecture is documented, it is assembled from parts anyone can buy access to, and it needs no operator sitting up at night. Autonomy also gives you something back. An implant that has to poll four providers before it acts generates more traffic and more noise than one taking orders from a single server, and it inherits the providers' refusals, quotas and response times as failure modes of its own. If you see a program talking to several model providers, opening a Discord address and reaching into LSASS at the same time, you do not need the malware's name to act.

Berigo recommends

• Map which programs and machines have a genuine reason to contact AI providers, and alert on everything outside that list.
• Alert on outbound traffic to Discord from servers and clients that have no business there.
• Correlate your alerts for LSASS access, injection into suspended processes and new WMI subscriptions, so that one reinforces the other.
• Take in the file hashes and the detection rule Talos published, and search your logs backwards for them.
• Look for run keys and WMI filter and consumer names carrying Windows Update names that did not come from Windows Update, and review scheduled tasks created with schtasks.exe.