VOLTA Malware Retries Until an AI Model Says Yes. Here's Where to Defend Instead.

Cisco Talos found an infostealer that asks a frontier model to rank each victim, then tries two other models if the first says no.

Ask any frontier model (the most capable models from the big AI labs) to write a dossier on a stranger, ranking what they own by how easy it is to steal, and it will probably refuse. That refusal is real. It is also, as of this week, about one line of code away from irrelevant.

On October 31, Cisco Talos published its analysis of VOLTA, a Windows infostealer (malware that grabs passwords, cookies and keys from an infected machine) with an unusual last step. After it collects everything, it hands a summary of the victim to a hosted AI model and asks for a "target assessment." If the model refuses, VOLTA asks a different model. Then a third.

The result is simple to say and uncomfortable to sit with. A model's refusal no longer stops the attacker. It decides which vendor gets the request.

That changes where defenders should spend their effort, and it carries a quieter lesson for anyone building AI products with automatic model fallbacks.

What VOLTA actually does

Strip away the AI part first, because most of VOLTA is an ordinary stealer.

According to Talos, it harvests saved browser passwords, cookies and payment cards, cryptocurrency wallets, Discord, Telegram and Steam sessions, Microsoft OAuth tokens (the login tickets that keep you signed in to Microsoft services), SSH and cloud keys, Wi-Fi passwords and screenshots. Then it uses the stolen sessions to dig further. Talos describes it searching a victim's Gmail for receipts to confirm a home address and pulling food delivery order history.

All of that lands in a local file called Identity_Report.txt. Talos says it can include a geolocated home address, employer, an inferred birth year, the last four digits of cards, and Slack workspaces.

Here is the new part. VOLTA sends that report, from the victim's own machine, to OpenRouter, a service that gives one API key access to models from many vendors. The system prompt casts the model as "a forensic intelligence analyst drafting a target assessment," and asks for sections including one titled "WHAT THEY'RE WORTH," which ranks the victim's valuables by how much they could earn an attacker, plus a "THEIR OPSEC" (operational security) section judging the victim's security habits.

Talos calls this "effort displacement." The model does not make the theft faster or bigger. It replaces the slowest human job in the operation: reading thousands of stolen logs and deciding which victims are worth an attacker's time. In Talos's words, the pattern is to "identify the step that requires the most sustained human attention and replace it with a model call."

The fallback chain is the whole story

The default model string in VOLTA's configuration is anthropic/claude-opus-4.6. Behind it sit moonshotai/kimi-k2 and then google/gemini-2.5-flash.

Talos writes that "VOLTA uses a multi-model architecture to fall back resiliently if it hits a model's refusal." The malware reads each reply, looks for phrases like "I can't" and "I'm not able," and when it finds one, moves down the list.

Think of it like a scammer calling a bank's phone line. If one agent says "I can't give out account details," the scammer hangs up and redials until a different agent answers. The first agent did the right thing. The bank still lost, because the policy only held at one desk.

That is why per-model safety, however good, cannot be the control you rely on here. Every refusal costs the attacker one more model request and a little extra waiting. And the attacker gets to pick the order.

There is an irony worth noticing. Builders use this exact pattern for honest reasons. OpenRouter's own model fallbacks feature takes a models array "in priority order," and its docs say "any error can trigger the use of a fallback model," including rate limits, downtime and "moderation flags for filtered models." VOLTA goes one step further and does its own text check, because a polite refusal comes back as a normal reply, not an error. The plumbing that keeps your chatbot up during an outage is the same plumbing that walks a stealer past a no.

Why the model is the wrong place to stop this

Look at the order of events. The theft happens first. Passwords, cookies, tokens and keys are already gone before any model sees a word. The model only sorts the loot.

So even a perfect refusal from every provider on the list would leave the victim robbed. It would just leave the attacker doing the sorting by hand, which is how stealer crews worked until recently.

Talos also notes that VOLTA can run "without the LLM stage altogether" when no API key is configured. The AI step is an upgrade, not a dependency.

And the operator needs no servers of their own. Talos reports that "all the observed endpoints for this malware are third-party controlled." That makes the infrastructure hard to take down and the traffic easy to mistake for normal API use.

Put plainly: the useful defenses sit where the stealing happens, on the machine and in how your credentials are stored. That is good news, because those are things you control.

Put this into practice

None of these need a security team. Start with the first two this week.

1. Watch for headless Chrome launched by the wrong process. Much of VOLTA's token theft depends on getting around Chrome's App-Bound Encryption, the protection Google added in 2024 to make cookie theft on Windows harder. Talos's countermeasure points at how that bypass works: Chrome launched in headless mode (no visible window). Its recommendation: an application control policy (a rule that decides which programs may run, or what they may launch) that restricts which processes may launch Chrome with --headless would "block the ABE decryption path entirely" (ABE is App-Bound Encryption), and at minimum you should alert when something unexpected does it.

If your company runs Microsoft Defender for Endpoint, an advanced hunting query against the DeviceProcessEvents table is a quick start:

DeviceProcessEvents
| where FileName =~ "chrome.exe" and ProcessCommandLine has "--headless"
| summarize count() by InitiatingProcessFileName, DeviceName
| order by count_ desc

Expect noise. Test runners, Puppeteer and Playwright scripts, and some build tools launch headless Chrome on purpose. The first run tells you what is normal. Allowlist those parent processes, then alert on the rest.

2. Move the keys a stealer can copy into hardware. Talos notes that "best practices for storing credentials in hardware backed stores also apply." The cheapest version for developers is an SSH key that lives on a security key, so the file on disk is useless without the physical device. GitHub's SSH key guide covers it:

ssh-keygen -t ed25519-sk -C "you@example.com"

SSH will normally ask you to touch the key when it connects. That small annoyance is the point. (GitHub's guide covers ecdsa-sk for keys that do not support Ed25519.)

3. Make cloud credentials expire. A stolen long-lived access key works until someone notices. Short-lived credentials from your cloud provider's single sign-on expire on their own, which shrinks what a stealer's haul is worth. Check your home directory for long-lived keys in plain text files, and retire the ones you can.

4. Rehearse the bad day. Talos's guidance if a machine is hit: preserve the %APPDATA%\volta_debug.txt log (it records what was taken), "revoke any potentially compromised tokens and change passwords," and treat any crypto wallet whose seed phrase sat in plain text as "fully compromised," moving funds to a new wallet generated on an air-gapped device (one that has never been online). Write down where you would revoke GitHub tokens, cloud keys and Slack sessions. Ten minutes now saves an hour of panic later.

5. If you build with model fallbacks, decide what a refusal means. Most fallback setups treat every failure the same way: try the next model. For uptime, that is right. For a refusal, it may not be. If your product sends user content through a chain of models, log refusals separately from errors and decide on purpose whether a "no" from one model should be retried on another. Your weakest model's policy is your product's policy.

Honest limitations

Talos's report leaves real gaps, and they matter for how far you take this.

It does not say how VOLTA reaches victims. Talos describes a builder template with "six swappable slots, filled in at build time," which suggests the author sells custom builds, but the delivery route is unknown.

It does not show which model actually answered. The configuration lists Claude Opus 4.6 as the default, and the debug log records whether the model call succeeded, but the report does not include a real model response from the wild. Nobody should read this as "Claude helped write dossiers." It shows that the malware asked, and was built to keep asking.

It does not say whether OpenRouter or the model vendors were notified. Provider-side detection of a stealer's API traffic is a reasonable hope, but nothing in the report confirms it.

And the defenses above are not complete. Headless Chrome alerts catch one theft path, not every stealer. Hardware keys protect SSH, not your browser sessions.

The shift

For years, the AI safety conversation around malware focused on whether a model would write the malicious code. VOLTA skips that question. Its author wrote the code. The model is a clerk hired at the end to read files and make a ranked list, and if one clerk refuses, the next one is a single function call away.

That makes refusals a speed bump, and it puts the real decisions back on your side of the screen: which processes may launch your browser, where your keys live, and how fast you can revoke them. Start with the headless Chrome query. It takes ten minutes, and the first run will tell you more about your machines than any model's refusal policy.

Sources: Cisco Talos, "Appraisal by AI: model-driven victim prioritization in the VOLTA infostealer" (October 31, 2026); OpenRouter model fallbacks docs; Google Security Blog, "Improving the security of Chrome cookies on Windows" (July 30, 2024); Microsoft Learn, DeviceProcessEvents; GitHub Docs, generating an SSH key for a hardware security key.