VOLTA Infostealer: Testing Which Stolen Credentials Survive Revocation

TL;DR

VOLTA-AUTODOXER is a self-deleting Windows infostealer that lifts browser sessions, Microsoft OAuth tokens, cloud CLI keys, SSH keys and saved Wi-Fi passwords, then posts an evidence bundle to a language model instructed to rank what the victim is worth. What decides your exposure is not the collection list but what still authenticates after your revocation runbook has run. Measure it on infrastructure you control: capture the same artifact classes from an authorized test workstation, execute your real revocation steps, then replay each artifact and record the response. Anything that still returns data is the finding.

What this is

An infostealer artifact re-validation test. You enumerate the credential material a stealer targets on an endpoint, apply the controls your organization believes revoke access, and replay each artifact against the real service to see which ones still work.

It is an authorization test with a different starting point. In a BOLA test you compare two accounts' access to the same object; here you compare one identity's access to its own resources before and after revocation, issued from a network position you do not control. The stealer supplies the threat model; the replay supplies the proof.

Keep three things separate, because incident reports blur them:

• What was on the host — the credential inventory.
• What the operator's model ranked as valuable — their triage, predictable from your own inventory.
• What your controls actually invalidated — the only measurement that changes your risk.

Why it matters

A single infected laptop is not one incident. It is an inventory of standing access: browser SSO cookies, a consented mailbox, a cloud CLI with cached application-default credentials, an SSH key for a jump host, the corporate Wi-Fi pre-shared key, and document metadata naming the author and their employer. VOLTA's distinguishing move is that it does not make the operator read that by hand — it serializes an evidence bundle and posts it to a model instructed to act as a forensic intelligence analyst, with a required section on what the victim is worth.

Two consequences:

• Partial revocation does not degrade into noise. If your runbook kills a password but leaves a refresh token, a service-account key or a PSK alive, the attacker's ranking stays accurate. Their prioritization improves as your revocation coverage worsens.
• A self-deleting implant with no attacker-owned infrastructure pushes detection onto identity and egress telemetry. You start from a token-use alert or an anomalous outbound POST rather than a sample, which means reconstructing the host's credential inventory yourself — the same work the replay requires.

How it works

VOLTA's collection pass is broad by design: Chromium passwords, cookies and saved cards; Firefox and Thunderbird; Outlook profiles; Slack workspaces; Steam, Battle.net, Discord, Telegram and Roblox sessions; SSH keys; cloud configs including gcloud and OpenVPN. It calls WlanGetProfileList to dump every saved Wi-Fi password in plaintext and runs an embedded cracker against crypto-wallet vaults inline rather than shipping them off-host.

The post-theft stage is the interesting engineering. Using the victim's own stolen sessions it searches Gmail for retail and delivery receipts to corroborate a home address, pulls order history from food-delivery sessions, and enriches the Discord account via the stolen token. The bundle — geolocation, employer and domain, inferred birth year, card last-four, document authorship metadata, iPhone backup indicators — is serialized and POSTed to https://openrouter.ai/api/v1/chat/completions.

The model configuration says a lot about intent: an Anthropic Claude Opus route on OpenRouter by default, falling back to Moonshot Kimi K2 and then Google Gemini 2.5 Flash. The client checks responses for refusal strings like "I can't" before moving down the chain, pins temperature at 0.2 for deterministic output, hand-assembles the JSON with no SDK, and sends a stock Mozilla/5.0 User-Agent.

Affected versions. VOLTA is malware, not a patched product: there is no affected-version matrix and no fixed release to check against. The durable artifact is the collection list above; the sample behavior, model endpoints and exact model IDs are documented in the Talos write-up in Sources.

Validation target. The test is a replay matrix over five artifact classes, run against your own services:

1. Session material — the browser cookie store (cross-referenced against Local State for the encryption key) and any bearer token cached by a CLI.
2. OAuth refresh tokens granted to a first-party or consented app on the mailbox.
3. Cloud credentials — service-account JSON and cached application-default credentials under ~/.config/gcloud.
4. SSH private keys and any VPN profile shipped with a certificate or key.
5. Network keys — the exported Wi-Fi profile and its PSK.

For each, the evidence standard is identical: the artifact itself (hashed, not pasted into the ticket), the exact request, the response status with a bounded body excerpt, the timestamp relative to revocation, and the control that should have killed it. A finding a second researcher cannot re-run is an anecdote.

Detection and response

Telemetry worth having before you need it:

• Endpoint. Non-system processes opening browser Login Data, Cookies and Local State; a WlanGetProfileList call from anything but a system component; directory walks over %APPDATA% profiles, ~/.config/gcloud and ~/.ssh; process exit followed immediately by file deletion, leaving an event log with no on-disk image.
• Network. HTTPS POSTs to openrouter.ai/api/v1/chat/completions, or to any unsanctioned LLM API from a workstation; JSON uploads whose User-Agent is a browser string with no browser session behind it.
• Identity. Refresh-token redemption from a new ASN or host shortly after a password reset; mailbox queries that look like receipt harvesting across several retail and delivery senders; Graph message reads by a token whose device has already gone off-network.

What a defender should verify rather than assume:

• Does egress control alert on an unapproved LLM endpoint from a host with no developer justification? Send one POST from a test machine and watch. If it does not fire, the whole AI stage is invisible to you.
• Does your SIEM join "password reset performed" to "token used from new ASN" for the same identity inside a day? Without that join, partial revocation leaves no trace.
• After someone presses revoke, does anyone re-replay the token to prove it is dead? Most teams have the button; fewer have the verification step.

What to do

1. Write the scope down first. Named test workstation, named test identity, an explicit list of services you will replay against, and a stop condition. Replaying real tokens against production mailboxes without that is an incident, not a test.
2. Inventory the test host. List the artifacts from the five classes above with paths and hashes. That is your endpoint attack-surface map.
3. Capture a baseline. Replay each artifact before any revocation and record status code, object identifier and one bounded excerpt — the "before" column.
4. Run your real runbook, not a scripted version of it. Password reset, session revocation (for Entra ID, POST /users/{id}/revokeSignInSessions), consent and refresh-token revocation, key rotation, device disable, and Wi-Fi profile removal plus PSK rotation if the host was on that SSID.
5. Replay in the same client, same order, same day. A 401 or 403 proves the control worked; a 200 with data is your finding.
6. Classify every artifact as killed, alive or partially alive. Partial is common — a token that still reads mail but can no longer send, a key that lists projects but cannot read objects. That is a smaller blast radius, not a clean result.
7. Check the metadata class separately. unzip -p contract.docx docProps/core.xml shows what a stolen file share hands an analyst's model. Decide whether that is acceptable on shared drives.
8. Fix what survived, then re-run. Token binding, shorter refresh lifetimes, conditional access on token redemption, per-workload keys instead of user keys, separate SSIDs for personal devices. Re-run the matrix after any identity-provider change.

FAQ

Does a password reset kill a stolen OAuth refresh token? Not by itself. Password reset, session revocation and refresh-token revocation are separate controls. Microsoft documents revokeSignInSessions as invalidating refresh tokens, but the app-consent model in your tenant determines what was issued and what scope it carries. Replay the token rather than trusting the documentation of a control you have never tested.

Which artifact should I replay first? The one with the widest blast radius and the least obvious revocation path: cloud service-account keys, then refresh tokens, then session cookies, then SSH keys, then the Wi-Fi PSK. Cookie invalidation is usually best understood; API keys and PSKs are usually worst.

Is the LLM stage a technique I have to defend differently? Not differently, but the detection is different. The model call is ordinary HTTPS to a third-party API — a policy and egress event, not a malware signature. And because the implant checks for refusals and fails over across three models, blocking one provider is not a control.

Can I detect the POST without breaking TLS? Sometimes. SNI, DNS and proxy logs show the destination; a stock Mozilla/5.0 User-Agent on a JSON POST from a host with no interactive browser session is a usable signal. Label it a policy alert, not a malware alert, and test that it fires.

When is a hit worth a full replay? If the host held any of the five artifact classes, it is worth the afternoon. The alternative is assuming a control worked because its button was clicked.

Sources

• Cisco Talos, "Appraisal by AI: model-driven victim prioritization in the VOLTA infostealer" — https://blog.talosintelligence.com/appraisal-by-ai-model-driven-victim-prioritization-in-the-volta-infostealer/
• Microsoft Graph, user: revokeSignInSessions — https://learn.microsoft.com/en-us/graph/api/user-revokesigninsessions
• NIST SP 800-63B, Digital Identity Guidelines (authenticator and session termination) — https://pages.nist.gov/800-63-4/sp800-63b.html
• OWASP WSTG, Session Management Testing — https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/
• OWASP Session Management Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
• Trusteed — https://trusteed.io