VOLTA infostealer ranks stolen accounts for attackers

VOLTA infostealer steals credentials and sessions from Windows PCs, then asks an AI model to rank the victim’s assets for an attacker by monetization using low/medium/high tiers.

Windows developer laptops expose more than browser logins

VOLTA collects personal-account sessions as well as data from Outlook profiles and Slack workspaces. According to The Hacker News, Cisco Talos researchers identified theft of passwords and cookies from Chromium-based browsers, plus collection of Microsoft OAuth tokens, SSH keys and cloud-provider keys. That is the scope I’d start with.

The collection covers Outlook profiles, Slack workspace data, payment cards, cryptocurrency wallet seed phrases, Wi-Fi profiles and screenshots. Discord, Telegram, Steam and Roblox sessions are targets too. Tom’s Hardware reports more: Thunderbird profiles, saved Wi-Fi passwords extracted as plaintext, and attempts to crack cryptocurrency-wallet vaults.

For a developer fleet, I’d put token exposure and cloud credentials ahead of reading the AI-generated prose. What can the attacker access? That is the question I care about first.

Talos characterises VOLTA infostealer as a mature stealer with a late-stage AI layer. The collection itself is familiar. The model turns that haul into an organised target assessment, leaving less analytical work for the operator. I’d describe that as the addition here, rather than let the AI label obscure the distinction between stealing the data and assessing it.

How does VOLTA infostealer ask AI to rank the haul?

VOLTA infostealer sends a structured evidence bundle to a model through OpenRouter, asking it to assess the victim’s valuables and security posture.

Talos describes a 240-word system prompt assigning the model the role of a “forensic intelligence analyst”. The prompt requires facts about the subject to come from the evidence bundle. Its required output includes “WHAT THEY'RE WORTH”, a ranking of valuables by monetization using low/medium/high tiers, and “THEIR OPSEC”, an assessment of security posture and password hygiene.

The configured model sequence spells out what gets tried next. One provider’s refusal need not end the analysis attempt. VOLTA has other models to call, in this order:

VOLTA infostealer checks replies for refusal phrases such as “I can't” and “I'm not able”. Tom’s Hardware also reports checks for thin replies and a hardcoded temperature of 0.2, interpreting the low setting as a preference for predictable output. Without an operator-supplied OpenRouter API key, VOLTA infostealer can still send its dossier over Telegram; the model analysis is not a prerequisite.

I’d read the valuation as an aid to attacker prioritisation, not independently established financial value. I’d keep that boundary intact, including in comparisons with the broader discussion of AI agents as insider threats.

VOLTA’s build template suggests resale, not confirmed distribution

The evidence for a commercial VOLTA builder is a template with six slots filled at build time, including a Telegram channel, API keys and settings. Talos considers resale plausible. There is another explanation. The Hacker News identifies the possibility of an author-controlled bespoke tool producing custom binaries for each order.

Tom’s Hardware reports that the slot credentials are encrypted but may be recoverable from the binary. It also interprets the service providers as chokepoints: delivering the assessments does not require attacker-owned infrastructure. I would keep both interpretations separate from any distribution claim. Neither recoverable credentials nor reliance on those providers establishes how widely VOLTA has been distributed.

Gmail receipts turn stolen accounts into a personal dossier

VOLTA infostealer uses captured sessions to gather more information and enrich the stolen data. Account access connects the person to an address, an employer and other identifying details.

The bundle can contain geolocation, home address, employer and employer domain, inferred birth year, card last-4 digits, Slack workspaces, document authorship metadata, iPhone backup indicators and a live Roblox account valuation. VOLTA infostealer searches Gmail for receipts from Amazon, DoorDash, Uber Eats, Grubhub, Walmart and PayPal to corroborate the victim’s home address.

Tom’s Hardware also describes collection of Uber Eats and DoorDash order histories, profile enrichment through a stolen Discord token, and Roblox item valuation through Rolimons. I’d keep that distinction explicit: the details come from those queries, not from a model inventing facts about the victim while writing its assessment.

The local report is named Identity_Report.txt. VOLTA serializes it to JSON for the OpenRouter request, saves the model’s reply as AI_Analysis.txt, then exfiltrates both files in volta_dox.zip. The inference request uses the victim’s own network connection.

Talos describes Telegram exfiltration at separate stages, not just delivery of the final archive. I would not use that archive as the sole reported transfer point.

Chrome headless controls block one decryption path

An application-control policy can block VOLTA’s reported Chrome App-Bound Encryption decryption path by restricting which processes may launch Chrome headless. Tom’s Hardware says the restriction limits access to Chrome-stored sessions, but does not prevent other theft, the AI stage or exfiltration. I’d keep the mitigation’s scope that specific.

Headless Chrome runs without a graphical interface. In the reported technique, launching Chrome in that mode forms part of the App-Bound Encryption bypass, so the control has to govern which process can initiate that launch. I would not stretch this technique into a general claim that browser encryption has become useless.

Preserve the log and replace exposed access

Tom’s Hardware reports that VOLTA’s main executable may delete itself. Its disappearance answers neither of the questions I’d ask next: what was collected, and did the model call succeed? The remaining volta_debug.txt records both.

1. Preserve volta_debug.txt. Keep recovered reports and archives as incident evidence too.

2. Review the preserved log. I’d read a copy. I would not rerun the suspected executable just to see what it does. In Windows Command Prompt, with the copied log in the current directory, this command displays its contents:

   type volta_debug.txt

3. Revoke or rotate all API keys and tokens. Tom’s Hardware recommends this regardless of apparent exposure. I would not restrict recovery to the credentials explicitly named in the preserved log; that is not the boundary of the recommendation.

4. Change passwords.

5. Move funds if a wallet seed phrase was stored in plaintext. Use a new wallet with a fresh seed, preferably generated on an air-gapped device. That is Tom’s Hardware’s recommendation for this situation, rather than continuing with the exposed seed.

During the review, treat the recovered dossier as sensitive material in its own right. It contains more than access credentials: the reported contents include personal information too. I’d account for both when deciding how to handle the recovered files, rather than treating the dossier as just another credential list.

NIK C2’s victim-funded AI calls are a separate mechanism

The fallback that uses a victim’s OpenAI API key belongs to NIK C2, a separate Windows remote-access tool discussed by Talos. It is not VOLTA’s OpenRouter integration.

The Hacker News reports that NIK C2 integrates an OpenAI client to analyse stolen data within the compromised session. If the attacker has not supplied an API key, the tool searches the victim’s environment variables for OPENAI_API_KEY and uses that credential. Talos describes the consequence directly: the legitimate account funds the attacker’s inference.

I’d keep VOLTA and NIK C2 separate in the incident report, while including AI-service credentials in the access inventory for an affected developer workstation. For the requests under review, check whose credential authorised each request and whose account paid for it.